BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / 173adoc.zip / RBBSDOC1.ASC < prev next >

Wrap

Text File | 1990-08-26 | 362KB | 6,957 lines

REMOTE BULLETIN BOARD SYSTEM for the Personal Computer Version 17.3A Technical Reference Guide Technical Support Numbers (407) 627-6969 (data) (407) 627-9767 (voice) (read section 4.1 before calling voice line) Copyright 1983-1990 by D. Thomas Mack 39 Cranbury Drive Trumbull, Connecticut 06611 DATA #1 -- (203) 268-5315 Ken Goosens 5020 Portsmouth Road Fairfax, Virginia 22032 DATA #1,2,3 -- (703) 978-6360 Doug Azzarito 5480 Eagle Lake Drive Palm Beach Gardens, Florida 33418 DATA #1 -- (407) 627-6969 #2 -- (407) 627-6862 August 26, 1990 RBBS-PC 17.3A TABLE OF CONTENTS i PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 1.1 The Philosophy Behind RBBS-PC . . . . . . . . . . . . . . . . 1-1 1.2 Distribution of RBBS-PC . . . . . . . . . . . . . . . . . . . 1-1 1.3 The "Contributions" Requested for RBBS-PC . . . . . . . . . . 1-1 1.4 How to Send Improvements . . . . . . . . . . . . . . . . . . . 1-4 2. INSTALLING RBBS-PC . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2.1 First Time Installation . . . . . . . . . . . . . . . . . . . 2-1 2.2 What's New In 17.3A? . . . . . . . . . . . . . . . . . . . . . 2-4 2.3 Upgrading To 17.3A . . . . . . . . . . . . . . . . . . . . . . 2-7 2.4 Common Problems Encountered Installing RBBS-PC . . . . . . . . 2-9 3. "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS . . . . . . . . . . . 3-1 4. RBBS-PC's SUPPORT POLICIES . . . . . . . . . . . . . . . . . . . . . 4-1 4.1 RBBS-PC's User Support Methods . . . . . . . . . . . . . . . . 4-1 Written documentation . . . . . . . . . . . . . . . . . . . . 4-1 "The Complete Electronic Bulletin Board Starter Kit" . . . . 4-1 "RBBS-PC in a Box" . . . . . . . . . . . . . . . . . . . . . 4-1 Network mail . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Technical Support BBS . . . . . . . . . . . . . . . . . . . . 4-1 Telephone support . . . . . . . . . . . . . . . . . . . . . . 4-1 Support Boards . . . . . . . . . . . . . . . . . . . . . . . 4-1 Help by Topic . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Professional Tech Support . . . . . . . . . . . . . . . . . . 4-3 4.2 RBBS-PC's Vendor Support Policy . . . . . . . . . . . . . . . 4-3 5. HOW TO GET A COPY OF RBBS-PC SENT TO YOU . . . . . . . . . . . . . . 5-1 6. FILES RBBS-PC USES . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 6.1 RBBS-PC Directory Structure . . . . . . . . . . . . . . . . . 6-2 6.2 RBBS-PC System Files . . . . . . . . . . . . . . . . . . . . . 6-3 6.3 RBBS-PC's Graphics Support . . . . . . . . . . . . . . . . . . 6-6 6.4 RBBS-PC Text Files . . . . . . . . . . . . . . . . . . . . . . 6-6 7. PLANNING YOUR USER INTERFACE . . . . . . . . . . . . . . . . . . . . 7-1 7.1 Menus Shown to Callers . . . . . . . . . . . . . . . . . . . . 7-1 7.2 Subsystem Prompts Shown to Callers . . . . . . . . . . . . . . 7-1 7.3 Commands Available to Callers . . . . . . . . . . . . . . . . 7-1 7.4 RBBS-PC's "Wrap-around" Command Search . . . . . . . . . . . . 7-2 7.5 How to Have a Single Universal Command Line . . . . . . . . . 7-2 7.6 RBBS-PC'S Programmable User Interface (PUI) . . . . . . . . . 7-4 7.6.1 An Example Using PUI . . . . . . . . . . . . . . . . . 7-5 7.6.2 How to Implement PUI . . . . . . . . . . . . . . . . . 7-5 7.7 RBBS-PC's Support of Sub-menus . . . . . . . . . . . . . . . . 7-8 7.7.1 How to Implement Sub-menus . . . . . . . . . . . . . . 7-9 7.7.2 Shared Options Across Sub-menus . . . . . . . . . . . 7-10 7.8 RBBS-PC's "Macro" Command Support . . . . . . . . . . . . . 7-10 7.8.1 How to Set Up "Macros" . . . . . . . . . . . . . . . 7-12 7.8.2 Macro Commands . . . . . . . . . . . . . . . . . . . 7-13 7.8.3 A Sample Macro . . . . . . . . . . . . . . . . . . . 7-18 7.8.4 On-line Data Base With Macros & Questionnaires . . . 7-19 7.9 RBBS-PC's "SmartText" Variables . . . . . . . . . . . . . . 7-21 7.10 "Colorizing" the RBBS-PC User Interface . . . . . . . . . . 7-24 7.11 RBBS-PC's Automatic Operator Page Option . . . . . . . . . 7-26 7.12 Enhancing the File View Function . . . . . . . . . . . . . 7-27 RBBS-PC 17.3A TABLE OF CONTENTS ii 7.13 Bulletins and News . . . . . . . . . . . . . . . . . . . . 7-28 8. UNIQUELY IDENTIFYING YOUR CALLERS . . . . . . . . . . . . . . . . . 8-1 8.1 Setting Up Identifying and Individuation Fields . . . . . . . 8-1 8.2 Preloading Identities For Instant Access . . . . . . . . . . . 8-2 9. RBBS-PC's AUTOMATIC SUBSCRIPTION/TIME MANAGEMENT . . . . . . . . . . 9-1 9.1 Setting It Up . . . . . . . . . . . . . . . . . . . . . . . . 9-1 10. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC . . . . . . . . . 10-1 10.1 Global RBBS-PC Parameters (Part 1 of 3) . . . . . . . . . . 10-1 10.2 Global RBBS-PC Parameters (Part 2 of 3) . . . . . . . . . . 10-3 10.3 Global RBBS-PC Parameters (Part 3 of 3) . . . . . . . . . . 10-5 10.4 Parameters for RBBS-PC System Files (part 1) . . . . . . . 10-8 10.5 Parameters for RBBS-PC System Files (part 2) . . . . . . . 10-10 10.6 Parameters for RBBS-PC "Doors" . . . . . . . . . . . . . . 10-12 10.7 Parameters for RBBS-PC's Security (part 1) . . . . . . . . 10-13 10.8 Parameters for RBBS-PC's Security (part 2) . . . . . . . . 10-15 10.9 Parameters for Multiple RBBS-PC's/Conferences . . . . . . . 10-17 10.10 RBBS-PC SysOp Utilities . . . . . . . . . . . . . . . . . 10-19 10.11 RBBS-PC's File Management System Parameters . . . . . . . 10-20 10.12 Communications Parameters (part 1) . . . . . . . . . . . . 10-22 10.13 Communications Parameters (part 2) . . . . . . . . . . . . 10-25 10.14 Parameters for RBBS-PC NET-MAIL . . . . . . . . . . . . . 10-25 10.15 New Users Parameters . . . . . . . . . . . . . . . . . . . 10-27 10.16 Use of the Library Sub-System . . . . . . . . . . . . . . 10-27 10.17 RBBS-PC's Parameters for Color . . . . . . . . . . . . . . 10-28 11. MODEM SWITCH SETTING AND CONSIDERATIONS . . . . . . . . . . . . . 11-1 12. RBBS-PC's FILE MANAGEMENT SUBSYSTEM . . . . . . . . . . . . . . . 12-1 12.1 Simple Directory Format . . . . . . . . . . . . . . . . . . 12-1 12.2 The Single and Chained FMS Directory Format . . . . . . . . 12-2 12.3 Advantages/Disadvantages of FMS Directory . . . . . . . . . 12-3 12.4 Creating FMS Directories . . . . . . . . . . . . . . . . . 12-5 12.5 Defining the FMS Category Codes . . . . . . . . . . . . . . 12-6 12.6 The "Library" Subsystem, CD-ROM, and FMS . . . . . . . . . 12-7 12.6.1 How the "Library" Subsystem Works . . . . . . . . . 12-9 12.6.2 The "Library" Subsystem and PC-SIG's CD-ROM . . . . 12-10 12.7 Creating the Personal Files Directory . . . . . . . . . . . 12-10 12.8 Automatically Checking & Converting Uploaded Files . . . . 12-14 12.9 Fast File Search . . . . . . . . . . . . . . . . . . . . . 12-15 13. SETTING UP ".BAT" FILES FOR RBBS-PC . . . . . . . . . . . . . . . 13-1 13.1 RBBS-PC's Startup Batch File . . . . . . . . . . . . . . . 13-1 13.2 The Daily Event .BAT file . . . . . . . . . . . . . . . . . 13-2 14. THE USE OF RBBS-PC "DOORS" . . . . . . . . . . . . . . . . . . . 14-1 14.1 A Quick Start to Installing Doors . . . . . . . . . . . . . 14-1 14.2 The Major Problems with DOORS . . . . . . . . . . . . . . . 14-1 14.2.1 Redirecting I/O . . . . . . . . . . . . . . . . . . 14-2 14.2.2 Exchanging Information . . . . . . . . . . . . . . . 14-3 14.2.3 Terminating After Carrier Loss . . . . . . . . . . . 14-3 14.2.4 Security . . . . . . . . . . . . . . . . . . . . . . 14-4 14.3 Invoking "DOOR"s Via The External Control File . . . . . . 14-4 14.4 EXITing or SHELLing to "DOOR"s . . . . . . . . . . . . . . 14-6 14.5 Resetting The User's Record Via a "DOOR" . . . . . . . . . 14-6 14.6 A Summary of "DOOR"s . . . . . . . . . . . . . . . . . . . 14-7 RBBS-PC 17.3A TABLE OF CONTENTS iii 15. THE SECURITY FEATURES OF RBBS-PC . . . . . . . . . . . . . . . . 15-1 15.1 RBBS-PC's Security Features . . . . . . . . . . . . . . . . 15-1 15.2 Examples of Uses for RBBS-PC's Security System . . . . . . 15-2 15.3 How to Implement the Password File . . . . . . . . . . . . 15-3 15.4 Implementing Security for Download Files . . . . . . . . . 15-5 15.5 Implementing Security for RBBS-PC Commands . . . . . . . . 15-7 15.6 Beware of the "Trojan Horse!" . . . . . . . . . . . . . . . 15-8 16. SYSOP FUNCTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 16-1 16.1 SYSOP Commands Within RBBS-PC . . . . . . . . . . . . . . . 16-1 16.2 SysOp Use of Function Keys and Numeric Pad . . . . . . . . 16-2 16.3 Local Status Display . . . . . . . . . . . . . . . . . . . 16-4 17. MESSAGE AREAS WITHIN RBBS-PC . . . . . . . . . . . . . . . . . . 17-1 17.1 "Conferences" and "Sub-boards" -- the Differences . . . . . 17-1 17.2 Making a "Conference" or "Sub-board" Successful . . . . . . 17-3 17.3 Setting Up a "Conference" or "Sub-board" . . . . . . . . . 17-4 17.4 Conference File Locations . . . . . . . . . . . . . . . . . 17-4 17.5 Establishing a "Conference" or "Sub-board" SysOp . . . . . 17-5 18. CALLERS AUTOMATIC NOTIFICATIONS OF MAIL WAITING . . . . . . . . . 18-1 19. RBBS-PC QUESTIONNAIRE FACILITIES . . . . . . . . . . . . . . . . 19-1 19.1 Branching to Labels . . . . . . . . . . . . . . . . . . . 19-2 19.2 Display Data Command . . . . . . . . . . . . . . . . . . . 19-2 19.3 Display Data And Get Response . . . . . . . . . . . . . . . 19-3 19.4 Multiple Choice Response . . . . . . . . . . . . . . . . . 19-3 19.5 Forward And Backward Branching . . . . . . . . . . . . . . 19-4 19.6 Raise/Lower User's Security Level . . . . . . . . . . . . . 19-4 19.7 Abort Questionnaire . . . . . . . . . . . . . . . . . . . . 19-4 19.8 Chain Questionnaire . . . . . . . . . . . . . . . . . . . . 19-4 19.9 Turbo Keys . . . . . . . . . . . . . . . . . . . . . . . . 19-4 19.10 Macro Execute . . . . . . . . . . . . . . . . . . . . . . 19-5 19.11 Assign Value . . . . . . . . . . . . . . . . . . . . . . . 19-5 20. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS . . . . . . . . 20-1 20.1 Parameters passed to a protocol driver . . . . . . . . . . 20-1 20.2 Calling external protocols using "templates" . . . . . . . 20-4 20.3 Parameters Returned by a Protocol Driver . . . . . . . . . 20-5 20.4 The Protocol Drivers Tested With RBBS-PC . . . . . . . . . 20-6 21. UPLOADED FILE TIPS . . . . . . . . . . . . . . . . . . . . . . . 21-1 22. DUE WARNING AND SYSOP'S LEGAL LIABILITY . . . . . . . . . . . . . 22-1 23. COMPILING AND LINKING RBBS-PC . . . . . . . . . . . . . . . . . . 23-1 24. LIMITED LICENSE . . . . . . . . . . . . . . . . . . . . . . . . . 24-1 25. LIMITED WARRANTY . . . . . . . . . . . . . . . . . . . . . . . . 25-1 26. THE HISTORY BEHIND RBBS-PC . . . . . . . . . . . . . . . . . . . 26-1 27. PROPOSED RBBS-PC SYSOP CONFERENCE . . . . . . . . . . . . . . . . 27-1 28. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD . . . . . . . . 28-1 APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 APPENDIX A -- RBBS-PC Record Formats . . . . . . . . . . . . . . . A-1 RBBS-PC 17.3A TABLE OF CONTENTS iv APPENDIX B -- RBBS-PC Software Registration . . . . . . . . . . . B-1 APPENDIX C -- RBBS-PC Subscription Service . . . . . . . . . . . . C-1 APPENDIX D -- Modems with RBBS . . . . . . . . . . . . . . . . . . D-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . D-1 Anchor Signalman Express (MK12) . . . . . . . . . . . . . . . D-1 Ark-Paradyne . . . . . . . . . . . . . . . . . . . . . . . . D-1 Everex Evercom 2400 . . . . . . . . . . . . . . . . . . . . . D-3 FASTCOMM 2496 Turbo Modem . . . . . . . . . . . . . . . . . . D-4 Leading Edge Series L 2400B Modem . . . . . . . . . . . . . . D-6 MICROCOM AX\9624c . . . . . . . . . . . . . . . . . . . . . . D-6 Prometheus 2400G . . . . . . . . . . . . . . . . . . . . . . D-7 USRobotics Courier and HST . . . . . . . . . . . . . . . . . D-7 USRobotics HST Dual Standard . . . . . . . . . . . . . . . . D-9 ZOOM Modem HC2400 . . . . . . . . . . . . . . . . . . . . . D-10 APPENDIX E -- RBBS-PC and the Hearing-Impaired . . . . . . . . . . E-1 APPENDIX F -- RBBS-PC And The AT's RS-232 Cable . . . . . . . . . F-1 APPENDIX G -- RBBS-PC And BASIC Compiler Patches for "Doors" . . . G-1 APPENDIX H -- Running a multiple node RBBS-PC . . . . . . . . . . H-1 APPENDIX I -- RBBS-PC in a DESQview Environment . . . . . . . . . I-1 1. Basic Hardware Considerations . . . . . . . . . . . . . . I-1 2. Modifications to DOS CONFIG.SYS and RBBS-PC batch files . I-1 3. What to Tell RBBS-PC's "CONFIG" Utility . . . . . . . . . I-2 4. DESQview Setup Default Settings . . . . . . . . . . . . . I-2 5. Adding RBBS-PC to DESQview's "Open Window" Menu . . . . . I-3 6. Memory Considerations . . . . . . . . . . . . . . . . . . I-3 7. Expanded Memory . . . . . . . . . . . . . . . . . . . . . I-4 8. How to AUTOEXEC RBBS-PC From DESQview . . . . . . . . . . I-4 9. Quarterdeck Utilities . . . . . . . . . . . . . . . . . . I-4 10. Redirecting I/O Considerations (DOS CTTY Command) . . . . I-5 11. FOSSIL Drivers - Break the 2-node Barrier under DESQview! . . . . . . . . . . . . . . . . . . . . . . . I-5 12. RBBS-PC Technical Support For DESQview . . . . . . . . . I-8 APPENDIX J -- Using RBBS-PC with DoubleDOS . . . . . . . . . . . . J-1 APPENDIX K -- RBBS-PC in a MultiLink Environment . . . . . . . . . K-1 APPENDIX L -- RBBS-PC in a CORVUS Network . . . . . . . . . . . . L-1 APPENDIX M -- RBBS-PC in ORCHID or AST PCnet NETWORK . . . . . . . M-1 APPENDIX N -- RBBS-PC in an Alloy PC-SLAVE/16 Environment . . . . N-1 APPENDIX O -- RBBS-PC and 10 NET Network . . . . . . . . . . . . O-1 APPENDIX P -- Running RBBS-PC on a NETBIOS network . . . . . . . . P-1 APPENDIX Q -- RBBS-PC and the IBM PCjr . . . . . . . . . . . . . . Q-1 APPENDIX R -- Using RBBS-PC to access ORACLE or dBASE Remotely . . R-1 Using dBASE "DOORS" with RBBS-PC . . . . . . . . . . . . . . R-1 Using ORACLE with RBBS-PC for On-line Data Base Access . . . R-3 APPENDIX S -- Using RBBS-PC with SEAdog to Access FIDO-NET . . . . S-1 APPENDIX T -- DOS Limitation on Running Programs Remotely . . . . T-1 APPENDIX U -- Recompiling RBBS-PC to Reduce Memory Required . . . U-1 PREFACE v PREFACE ------- This document discusses the technical aspects of installing, configuring and running RBBS-PC. You should already be familiar with the following subjects in order to fully understand the concepts presented in this document: - Modem communications - DOS file organization - DOS Batch files Consult your modem owner's manual, and your DOS command and technical references for details on these items. Conventions: ------------ This manual makes extensive use of examples. The following conventions are used: - Items in CAPS are to be entered as shown. - Items in lowercase, or surrounded in <.> are "replaceable" parameters. - Filenames with "wild cards" represent a group of files. The "*" and "?" wildcards are used as in DOS. "?" represents any single character, while "*" represents one or more characters. Tools you will need: -------------------- To install and configure RBBS-PC, you will need a TEXT editor that can edit DOS text files. Most word processors imbed "control" characters in documents, but also allow documents to be saved in "ASCII" or "non- document" mode. RBBS-PC's text files can have no TABS or control characters (other than ANSI color commands) in them. You will also find it useful to have a "test" computer available, with a separate phone line. In this way, you can call your RBBS-PC and see the connection from both ends. While not essential, a test machine can be extremely helpful during configuration. About this Document: -------------------- This document was created using Word Perfect 5.1. It represents the work of dozens of contributors, and was compiled and edited by Doug Azzarito. Your comments and suggestions are welcome. If you would like a copy of this document formatted for a specific printer, contact Doug Azzarito on the BBS listed on the title page. INTRODUCTION 1-1 1. INTRODUCTION --------------- RBBS-PC is a Remote Bulletin Board System for the IBM personal computer, hence the name RBBS-PC. RBBS-PC's primary application is a "host" communications package. This allows a System Operator (SysOp) to control a system that lets "remote" callers use the host computer for many functions, including: - the dissemination of news and bulletins - electronic mail between users - exchange of programs and data - taking surveys and placing on-line purchase orders - or playing games. RBBS-PC is a "full featured" bulletin board system that not only supports a broad range of functions, but runs "multi-user" under networks and multi-taskers. RBBS-PC can also run as a "local" application in which the "user" does not connect through a telephone line, such as on a local area network. 1.1 The Philosophy Behind RBBS-PC --------------------------------- RBBS-PC is given away freely, with source code. Its authors and contributors neither ask for nor receive any money for their work. RBBS-PC is "Userware", meaning that it is supported and enhanced by the community of people using it, who believe that what is shared becomes better than it was. It is hoped that RBBS-PC will be used as a catalyst for the free exchange of information, an educational example of communications programming, and an irrepressible political force that puts the power of information in the hands of the many. 1.2 Distribution of RBBS-PC --------------------------- Each new version of RBBS-PC is initially sent to the CPCUG's Software Exchange for distribution. CPCUG is a Maryland Corporation whose "legal name" is the Capital PC User Group, Inc. The CPCUG is an all-volunteer, non-profit organization according to Section 501C3, Social Welfare, of federal law. All revenues are re-invested in and applied toward CPCUG's education programs. There is no fee at all for using or distributing RBBS-PC. Indeed, no one can charge for its use or distribution, though user groups and commercial distributors of software can recover their costs but not charge anything for RBBS-PC itself. RBBS-PC can also be downloaded from hundreds of bulletin boards across the country. If the BBS you are calling is running RBBS-PC, chances are good they will also have the files in their library. 1.3 The "Contributions" Requested for RBBS-PC --------------------------------------------- RBBS-PC lives and dies by the unremunerated contributions of it's user community. Four types of "contributions" are requested for RBBS-PC: A. Modifications to RBBS-PC, itself, that are documented and distributed as .MRG files against the "base-line" source code that other SysOps might elect to incorporate into their version of RBBS-PC. Remember that RBBS-PC can be distributed in modified form only with permission. Distributing a modified EXE (executable) file without RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 1-2 permission violates both the RBBS-PC copyright and the limited license granted with it's use. B. Publicly distributable software. It can either be "public domain" (i.e. software which the author has relinquished all rights and which may be appropriated by anyone for use in any way), or publicly distributable software (i.e. software in which the author has retained the rights and which may only be used according to the conditions under which the author has designated). C. Equipment or services. If you or your organization can donate equipment, software, supplies, or services to support the RBBS-PC development effort, feel free to do so. Contact any of the authors (listed on the title page of this document) if you wish to discuss equipment donations. D. Money - the last level of "contribution". Money is the one commodity that we are willing to exchange without first having obtained the respect or consideration of the other party. It is perhaps the easiest to give as it exonerates us from the other levels of "contribution." RBBS-PC development is an all volunteer effort, so money is never plentiful. However, when equipment donation is not possible, spare cash can often buy a piece of hardware that requires experimentation before RBBS-PC can support it. Remember, money is not the best or even the second-best type of "contribution" you could make. Independent of any donations of enhancements to RBBS-PC, publicly distributable software, equipment, services, supplies, or money, please consider becoming a member of CPCUG. Simply send your name, address, and phone number along with $35 to CPCUG, 51 Monroe Street, Plaza East Two, Rockville, MD 20850 or call their membership hot line at (301) 670-1737. If in the final analysis you feel that you can do none of the above, - remember those who have, - enjoy what they have nurtured, and - keep the faith with those who have gone before you. RBBS-PC is what it is today only because of the freely donated time and work of many contributors. Contributions have included suggestions, software fixes, significant enhancements, improved documentation, and utilities. Some of the individuals named here have continued their contributions to RBBS-PC even to the current release. Others have gone on to pursue different interests. But whether mentioned below or not, their contributions live on in RBBS-PC. In their contributions to RBBS-PC's on-going growth, each has paused to give of themselves without hope of reward by practicing RBBS-PC's fundamental principle -- "users helping users." INTRODUCTION 1-3 While we have met very few of these people personally, those names we remember are: Doug Azzarito Ray Horton Harvey Pierce Jeff Batdorf Gary Howrith Danny Plunkette Rod Bowman Charlie Innusa Lee Pollard Matthew Briggs Loren Jones Jeff Porter Randy Brodersen Larry Jordan James Reinder Mike Brown Robert Jueneman Joel Ricketts Sam Brown Vern Kallegin Kurt Riegel Mike Button Dave Kleinschmidt Jacques Rodrique Vince Castelli Steven Kling Dick Rohradnz Rob Cecchino Kim Kodde Rich Schinnell Tom Collins Blaine Korcel Mark Seiden Drew Commins Ronald Koridon Rosemarie Siddiqui Ezra Conger John Krytus Andrew Silber Ed Copley Mark Lautenschlager Carl Slaughter Richard Couture Steve Lieber Samuel H. Smith Bob Cramer Steven Linhart Gregg Snyder Dave Crane Joseph Lionelle Robert Snyder Daryl Damon Scott Loftesness Carl Spencer Everett Delano Harry Logan David Staehlin Francis Dorer Gene Lowry Stan Staten Peter Eibl James Ludwick Terry Steichen Warren Fox Kevin Lutz Dorn Stickle John Friel D. Thomas Mack Randy Sun Jim Fry Robert Mahoney Terry Taylor Asa Fulton Matt Malden Jan Terpstra Kent Galbraith Carl Margolis Arnold Thomsen Mitch Geier Sidney Markowitz Daan van der Weide John German Jon Martin Rick Wadowski Read Gilgen Louie McCaw Clark Walker Ken Goosens Wes Meier Kim Wells Ray Gwinn John Morris Bob Westcott Dave Hacquebord Bill Newkirk Robert White Steve Harrison Jeregen Nordhausen Yew Seng Tan Gary Hoff Vince Perriello Special thanks goes to SysOps who helped sponsor enhancements to RBBS-PC, including Ken Rogers of the United States Department of Commerce ECONOMIC BULLETIN BOARD who encouraged configurable identification and individuation, Loren Jones of The Center for Law and Computers at the Illinois Institute of Technology's Chicago-Kent College of Law who contributed to subscription support, John Rittwage of the American College of Obstetricians and Gynecologists who helped support submenus and the programmable user interface, and Brian Kelly of National Credit Appraisals and Reporting, whose special needs prompted the development of personal downloading. To those whose names have not been mentioned -- apologies are extended. Take comfort in knowing that you live on in the work that you have wrought. In an age of cynicism, RBBS-PC and the Userware concept represents an opportunity for each of us to give back to the world something a little better than when we found it, and is something that the authors of RBBS-PC believe in strongly. To each of the contributors to RBBS-PC, we would like to say personally, "We are very proud of the company that RBBS-PC keeps." RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 1-4 1.4 How to Send Improvements ---------------------------- RBBS-PC continues to evolve and be "debugged." The following coding conventions have been helpful in the past and you are requested to observe them in the future: Updates consist of two types of ASCII files. One called *.MRG which are the BASIC source statements for the particular base-line source code component of RBBS-PC to be updated. The lines that have been modified are indicated as being so modified with a comment beginning in column 70 in the format as follows: 4330 CALL QuickTPut("This line has been changed!",1) ' DA091402 The comment in column 70 consists of the changer's initials, the month and day of the change, and a sequence number. Thus, the comment DA091402 means Doug Azzarito made this change on Sept 14th, and it was the second change he made that day. These .MRG files can be applied to the base-line source code via Ken Goosens' Batch Line EDitor utility program (BLED). The BLED utility can easily create .MRG files as it has both a file compare and file merge function that is specifically geared to the new BASIC compiler's capabilities that allow lines of source to be unnumbered. The second file type is called *.DOC. It describes on a line-by-line basis the specific functions added or bug that was fixed. The .DOC file is what allows us to integrate several .MRG files and resolve whatever conflicts that may exist. Each incremental release of RBBS-PC beyond 17.3 will include updates to the base-line documentation. When possible, these updates will be in the form of replacement pages to be inserted in the baseline documentation. The RBBS-PC naming conventions of 99.9X are roughly as follows: 1. If a significant change to source code or logic occurs, the first two digits of the release level will change (i.e. 14.1 was followed by 15.1). Such changes usually include system file format changes requiring a "reconfiguration." 2. If a new feature or enhancement is added the digit following the decimal point is incremented by one (i.e. 17.2B was followed by 17.3). These changes usually do NOT require "reconfiguration." 3. If a "bug" is being fixed, the letter at the end of the version number is incremented (i.e. 17.2A was followed by 17.2B). These "maintenance" releases contain no new significant features, but often fix troublesome bugs in the previous version. With each maintenance release, a .MRG file name such as 17-3A.MRG and a corresponding 17-3A.DOC file will describe the changes. The first maintenance version is always "A". 4. As bugs are reported and fixes found for the current release of RBBS- PC, the source code corrections are distributed via an RFIXmmdd.ZIP file. This contains the necessary files to apply the "temporary fixes" against the released version of the source code and re-compile the source code. The recompiled .EXE files are distributed via a file named RFIX-EXE.ZIP. INTRODUCTION 1-5 The purpose of these conventions is to allow everyone to know what RBBS-PC level they are running under and understand the logic behind the changes/fixes as they occur so each SysOp can evaluate them for his own needs. When you logon to RBBS-PC the version will be displayed. If you have comments or fixes, please let us know so that they can be reflected in the RBBS-PC program and shared with all other users. You can do that by sending your changes by mail to: Ken Goosens 5020 Portsmouth Road Fairfax, Virginia 22032 or uploading the changes to Ken Goosens' BBS at 703-978-6360. All comments and suggestions are welcome, but those that are come with source code changes carry more weight. INSTALLING RBBS-PC 2-1 2. INSTALLING RBBS-PC --------------------- RBBS-PC is a powerful application that may take months to master fully, but gives those who stick with it a practically ever expanding power as their knowledge and needs grow. But it is not necessary to understand everything or take advantage of all its power, before it can be set up initially, or used. This section is intended to provide a step-by-step approach to setting up RBBS-PC. Follow the steps thoughtfully! Do not proceed to subsequent steps until you understand all the previous steps. Our goal with persons getting started with RBBS-PC for the first time is to get them off to a fast start by (a) bringing up the software to see how it runs, and (b) getting the software to be able to answer an incoming telephone call. A BBS strongly reflects the interests and personality of it's SysOp, and RBBS-PC is one of the most flexible and customizable of the BBS's. However, for those who are NOT familiar with electronic bulletin board systems in general, a good introduction to installing RBBS-PC is contained in the book "Electronic Bulletin Board Starter Kit" by Charles Bowen and David Peyton, published by Bantam Books. The book does in 436 pages what the next few pages attempt to do. It is a superb guide for someone who has never setup a bulletin board system or is not knowledgeable about PC or asynchronous communications. The book comes complete with an extensive index as well as a copy of RBBS-PC Version 15.1C and, of course, the associated source code. Since all versions of RBBS-PC are upward compatible, this book serves equally well as a guide for the uninitiated to all subsequent versions of RBBS-PC. This book guides the potential SysOp in easy stages from unwrapping the two diskettes that are included with the book to operating the more advance features of RBBS-PC. The book was published by Bantam Books in August of 1988, ISBN 0-553-34552-4, and can be found in most technical book and computer stores. It addresses the topic of installing an electronic bulletin board system in a far better way than this "Technical Reference Guide" does. Because RBBS-PC attempts to provide SysOps the maximum flexibility, it is perfectly possible for those setting RBBS-PC up for the first time to shoot themselves in the foot. Be patient with yourself. Remember that things worth achieving usually are not obtainable without effort. 2.1 First Time Installation --------------------------- Do not try to do everything at once. Keep things simple and proceed patiently, a step at a time, putting only one thing in place. The files you need are the executables (RBBS-EXE.ZIP) and system text files (RBBS-TXT.ZIP). RBBS-PC comes completely set up, ready to run. To take advantage of this set up, you must do the following: 1. Create a new subdirectory on the hard drive of your computer. "RBBS" is a suggested name but any can be used. The DOS command to make the directory is "MD \RBBS". 2. Copy the zipped files into the subdirectory. You must have at least RBBS-EXE.ZIP and RBBS-TXT.ZIP. The DOS command to copy is "COPY <from> <to>", e.g. "COPY A:*.ZIP C:\RBBS". 3. Make the subdirectory you created your current one ("CD \RBBS"). RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-2 4. Unzip the files using the command "PKUNZIP -d *". You need to obtain a copy of the program "PKUNZIP.EXE" to do this. Subdirectories will be created off the current directory. 5. Enter the command: INSTALL. This program will check the directory structure, and inform you if any files are missing or misplaced. It also makes sure the RBBS-PC configuration matches your system. The file INSTALL.LOG will contain information about files the install procedure could not find, or had to move. While many of the files are OPTIONAL, consult this log if you later encounter problems running RBBS-PC. You are now ready to run RBBS-PC! RBBS-PC comes with a sample configuration file, and small but empty users and messages file. To bring up RBBS-PC, at the DOS prompt, type RBBS[Enter] where "[Enter]" means to press the "Enter" key. RBBS is a batch file that runs RBBS-PC, and also controls certain RBBS-PC maintenance functions (see section 13 for details). In this first run, RBBS-PC does not to wait for a telephone call to establish communications through a serial port, but just runs as a local application, communicating with you through the screen and keyboard. You should see a copyright notice first, then a "WELCOME TO RBBS-PC", a short message about a "prelog", and then be asked "What is your First Name?" What you see on your screen beginning with the "WELCOME" is exactly the same as a remote caller on the telephone line would see. Instead of your real name, enter SECRET NAME[ENTER]. This is the "secret SysOp name" for the sample system. Next, answer the questions RBBS-PC asks you and look around. Your only goal at this point is to make sure that the software runs on your computer. The next goal is to get RBBS-PC to answer an incoming call. This requires a functioning communications port, modem, and telephone line, as well as more configuration information in RBBS-PC. There are five things you must normally do in preparation: (1) Set the RBBS-PC modem commands properly for your modem, especially the modem initialization string and firmware initialization string (See CONFIG parameter 225). (2) Set the hardware switches on the modem properly, but some modems, especially "internal" modems, may have no hardware switches. (3) Set the communications port to what the modem is using (see CONFIG parameter 221). (4) Initialize the modem's firmware. This makes permanent the settings that RBBS-PC needs (see CONFIG parameter 231). In the best of all worlds, the factory settings of the modem are what RBBS-PC wants and RBBS-PC's default settings work, so that nothing at all must be changed. This is normally the case for the USR Courier 2400 modem. Your key to setting everything up is the RBBS-PC configuration program called "CONFIG.EXE". CONFIG is your guide to configuring RBBS-PC for your preferences and environment, and basically is just a smart editor for INSTALLING RBBS-PC 2-3 setting up RBBS-PC. RBBS-PC stores its configuration parameters in a file called "RBBS-PC.DEF". To edit configuration file RBBS-PC.DEF, just type CONFIG RBBS-PC.DEF[Enter] You will see a copyright notice, CONFIG will read in the current values, and then you will see a table of contents for the many pages of parameters you can set. There are over 300 parameters you can set in RBBS-PC, which can be extremely complex. Most you will never change, but RBBS-PC has tremendous power and flexibility if and when you do need it. You can just press the page down key "PgDn" to see the many screens of parameters, if you want to browse. Do not be intimidated. RBBS-PC, as shipped, has nearly all of these parameters set for you. For more information, read section 10. Once you have set the modem parameters in CONFIG, and saved your changes, you are ready to make sure that RBBS-PC will answer incoming calls. Be sure you have your modem connected and on. Then type RBBS[Enter] You should see a copyright screen. RBBS-PC will draw a screen with boxes. The modem lights should flash, and RBBS-PC should display "Ready for Calls" in a box. Four lights on an external modem will normally be on: High Speed (HS), Auto Answer (AA), Modem Ready (MR), and Terminal Ready (TR). Ideally, you have a second computer beside the first with a modem and telephone line that you can use to call the BBS. Otherwise, have a friend with a computer call it. You need to call with a modem to make sure that the two modems will talk. When the call comes in, the Ring Indicator (RI) should blink. Then the Off Hook (OH) and Carrier Detect (CD) lights should come on as the modems link. And RBBS-PC should chip in with its opening "WELCOME TO" line, and the send (SD) and receive (RD) lights should blink periodically. If the lights blink but you see nothing, you may need to turn on "snoop" so you can see the session on your local terminal. Press F9. If that doesn't do anything, press it again. After the caller says "Goodbye", RBBS-PC should recycle, the CD and OH lights go off, and the box reappear that finally says it is again ready for calls. Once you have RBBS-PC answering calls, you are ready to begin customizing the board, setting it up the way you want, and adding features. You need two primary tools: CONFIG.EXE (part of the RBBS-PC package), and a full screen editor (which you must supply). You need what is called a "programmer's" editor versus a word processor - one that only puts in what you type and never inserts any hidden or special characters - what is sometimes called as straight "ASCII" editor. Here we will walk you through what is behind what the caller sees on logon. The first message is "WELCOME TO " followed by the name of the board, as specified in CONFIG parameter 12. Next the file PRELOG is displayed. This file need not be present, and generally should be brief, as it is displayed on every call. Callers are then asked to identify themselves, by answering the question "What is your FIRST name?" The text after "your" can be set up with CONFIG parameter 45, though most SysOps do not change it (e.g. "What is your ACCOUNT ID?"). The next question is "What is your LAST name?", which can be set in parameter 46. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-4 If the caller is not in the user's file, which normally means that this is a new, first time caller, then RBBS-PC displays the text file called NEWUSER. Here you should explain the board and the rules you have for people to follow. Callers next see a welcome specific to their security level, called a "logon level greeting file". These files take the form LGnn.DEF, where "nn" is their security level (e.g. level 10 callers would see the file LG10.DEF, if it is present in the default directory). Then, a general "welcome" file is displayed. The general welcome file shown to the caller can be changed "on the fly" by RBBS-PC, dependent on what sort of Graphics option the caller has selected. SysOps often use this for an ANSI log-in screen. There are many other things in RBBS-PC you will want to set up, such as bulletins, news, and conferences. Just remember to take your time. RBBS-PC almost always runs the FIRST time. Make one change at a time and then test it so you don't break something that once worked. 2.2 What's New In 17.3A? ------------------------ 17.3A is a maintenance release for 17.3. Over 100 changes were made to the code. The most significant are: (a) increased reliability, eliminating the following problems: - occasional constant recycling with "connect timeout" - overflow error when modem not working right - untrapped errors, when FMS directory wrong and when trashcan file not set up properly - possible infinite loop in FMS search - possible incorrect modem initialization in CONFIG - problems with execution of external events after 9pm. (b) autodownload now works properly (c) problems with macros were fixed, including repeat of prompts, double execution of a macro, assigns sometimes getting wrong values, problem with block print, problem with PUI's, and macros associated with a protocol not being executed. (d) problems fixed with doors include individuation not restored, doors need not be listed on the menu if in DOORS.DEF, the registration door will respect DOORS.DEF, and bytes downloaded is now right dooring to external protocols. (e) problems fixed with messages/conferences include mail waiting in a conference view works properly for the conference you are in, message display can be paused and interrupted, searches on subject work right if subject not in upper case, TABS works in message entry, person with SysOp status does have mail to SysOp listed in mail scan, public name of SysOp recognized as SysOp, no longer says receiver will be notified of new mail when not in user's file, join to main works in conference view function, support added to allow names to have a netmail address ("@ <node>" on end), and subject prompted for in message entry after a canceled comment to SysOp. INSTALLING RBBS-PC 2-5 (f) problems fixed with the callers log include time logged on is not right when join conferences, and more information is included for local users. (g) Features were added to the Fast File Search to better support macro processing (see section 12.9). (h) The documentation was also rewritten in 17.3A. Many new examples and explanations of features were added. (i) The conference V)iew command now resumes any listing after the last conference listed, rather than restarting at the top each time." Previously, version 17.3 of RBBS-PC added the following enhancements: (a) Search for a file's existence on upload and download has been vastly speeded up. Based on an indexed binary search of a sorted list of file names. (b) Data base function to forward search (jump to a line containing a particular string and continue from there) was added for all file and text displays (c) NEWS facility that automatically displays news since last on to callers (d) Callers can now stack commands to virtually any depth, and stacking is consistently supported everywhere. (e) Modem commands can be selected based on modem model. (f) Users may now FORWARD their mail to another user. SysOps or users having sufficient security to edit a message can forward it to anyone as well as change anything in the message header. (g) The MSG header Security change now allows the SysOp to change ANY field in the header. (h) When reading mail, the SysOp can instantly edit the USER record of the message sender, then return to reading. The specific enhancements added include: (1) When you have insufficient time to download all the files requested, RBBS-PC will inform you of the files omitted but try to download what there is time for instead of canceling the entire download request. (2) Timelock message now shows minutes & seconds left in time lock. (3) Command stacking now supported consistently and to virtually any depth. (4) Autopage message less stiff and formal when caller notified that SysOp wanted to know caller logged on. (5) Chat time given back when SysOp initiates chat and no longer counts against session time. (6) Conference name added to message header. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-6 (7) Support for new ZIP imploded compression. (8) NEWS facility added. Special bulletin displayed automatically on logon when updated since user last on. (9) Message quoting first gives the edit command prompt but tells how to continue adding to a reply. (10) Default extension automatically added to uploads and downloads when no extension is specified (11) Forward search added to all directory displays and text file displays (12) Delays and embedded returns can be put into modem control strings. (13) Caller shown on welcome line if connection is reliable (14) SmartText can control whether substituted value is inserted or overlaid (15) SmartText can control whether substituted value is trimmed of leading and trailing spaces first (16) Caller is informed when session time is shortened because of an external net mail event. (17) Can use "s" for since last listed on file N)ew command (e.g. "n s u" for list new files since last on in upload directory). (18) When replying to a message, will automatically continue if person sending mail to is not in the user's file, rather than asking the user whether wants to re-enter name or continue. (19) Macro questions can have edits forcing answer to be one of a list or between two values. (20) Protocols to be used to download and upload can be specified anywhere in stacked command line rather than just on end. (21) File searches on up and downloads have been vastly speeded up. Makes a huge different on slow devices like CD-ROMs. Also, have ability to trigger OFF LINE processing for files elsewhere. (22) CONFIG gives option to set modem commands based on modem model. Uses external file MODEMS.SET in default drive/path. Makes RBBS-PC much easier to set up. (23) SysOps can now track UL/DL's and have a "free download" period. (24) SysOps can now explain exactly what a REGISTRATION EXPIRES means. The HELP file RGXPIRE.HLP is seen when a user is warned, and RGXPIRD.HLP is seen when RBBS-PC reduces a caller's access. (25) Support for 38,400 bps, but only through Fossil drivers. (26) Can have multiple extensions searched when trying to detect duplicate on upload (new CONFIG parm 169). INSTALLING RBBS-PC 2-7 2.3 Upgrading To 17.3A ---------------------- 17.3A is virtually "plug compatible" with 17.3. You need only: - replace RBBS-PC.EXE and CONFIG.EXE with the new versions - add the new help file "HELP07" to your other help files - in parameter 225 of CONFIG, add "AT" in front of your firmware write command - replace your MODEMS.SET with the new one - replace MENU5C, for doors, with the new one (edit in your door names), unless yours is not based on the standard one When upgrading from a version PRIOR to 17.3, follow these steps: 1. Do not destroy or overwrite your old files. You may run into difficulties and have to fall back to the old version. Especially keep a backup of your current USERS, MESSAGES, configuration "DEF" files, and your RBBS-PC.EXE and CONFIG.EXE files. 2. Start by trying to get the new version just to run equivalently to the old without implementing new features. Implement new features one at a time. Do not try to implement everything new at once. 3. The file that almost always changes between non-maintenance versions is a configuration "DEF" file. A utility program called RECONFIG.EXE is provided that converts all versions from 14.1D on to the latest. This will save you the trouble of manually re-entering the parameters. If you do not have RECONFIG you should print out all the options you selected on your current RBBS?PC.DEF file. 4. CONFIG.EXE has an option to review the parameters changed since the last version. You should always run this to see what is new and possibly change the values. If you do not have RECONFIG, you generally need to delete your current RBBS?PC.DEF file and manually enter the parameters. Sometimes, however, the same parameters will be in a different place in the new configuration. If you are upgrading from several versions back, there is no simple way of knowing what all is new. 5. The MESSAGES and USERS files are the two that are most important to continue to be able to use. RBBS-PC 17.3 is compatible on both accounts with files at least back through version 14. However, there is a critical parameter to set in CONFIG: the minimum security to auto-add a user to a conference. This applies to conferences not sub-boards, i.e. that have no configuration DEF file. Go into CONFIG, conference mode, and then check this value. No one will be able to join the conference if their security is below this number, even the SysOp. Reset this value so that the desired callers can join the conference. 6. RBBS-PC is written to be upward compatible, preserving all the functions of earlier versions. However, you may have to make changes to the new configuration to make it run equivalently. If upgrading from 17.2x, you need to consider the following: (a) replace RBBS-PC.EXE and CONFIG.EXE RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-8 (b) If you want file a)ll to list multiple physical directory files (as opposed to say just the FMS master file), then you must set up RBBS-PC differently (see CONFIG parameter 218). (c) If you turned on "enforce ratios", but exempted all security levels (this tells RBBS-PC to track, but not restrict, downloads), you must change the ratio (parameter 9 in PASSWRDS) to -1 in order for the code to work equivalently. Similarly, a ratio of 0 will not even COUNT the downloads. (This allows "free" periods of downloading to be specified.) 7. If upgrading from 17.1, you need especially to consider: (a) the minimum security to read and kill all messages. If this is set to 0, everybody can read everyone else's mail! (b) RBBS-PC formerly supported the "arc" format exclusively. Now "zip" is its default, but it can be set up for any. Review the parameters for default extension and archiving command. (c) Your personal directory may not work unless you include a drive/path. Re-enter the parameter value in CONFIG. 6. If you are upgrading from a version prior to 17.1, consider the possibility that the PASSWRDS file may have a different format, that external protocols are controlled by an external table (PROTO.DEF), that the doors interface may be different, and the control for an timed even may be different. See section 10 for information on these CONFIG parameters. 9. Use the new text files, especially the menus and help files. If you have customized versions of these, start with the distributed files and change them. 10. Review the documentation on the major areas of enhancements. Section 26 on the history of RBBS-PC briefly reviews the enhancements in each version of RBBS-PC. Some specific things that you want to take advantage of include: (a) Macros and SmartText have been significantly improved in 17.3. You no longer need to include a "{ST" at the end of macros and will probably want to omit it. You may want to enhance your menus as well. See the revised sections on SmartText and Macros. (b) You may want to make file searches faster and reduce the wear on your hard disk by installing the fast file search system. See section 12.9. (c) You may want to create a new category of system bulletins - a NEWS facility (see section 7.13). The major changes in 17.2A were: (a) use of shelling triggered by the presence of BAT files to test uploads for integrity, convert uploads to a different format, and support viewing of text files inside ZIP files, and verbose list any compressed format, INSTALLING RBBS-PC 2-9 (b) greatly enhanced macros and questionnaires, including new data base functions, (c) enhanced doors interface, including an external control file for doors (DOORS.DEF) as well as the ability of a door to request that RBBS-PC change the user record (DOUTx.DEF), pass any information via command line or a file to a door, and for a door to return information to be displayed to the caller (d) the message files can be configured to have minimum size to hold the messages and let grow in size as new messages are added, (e) conferences and sub-boards can be configured to automatically change the user's security to match the logon security, (f) message quoting, allowing the option to type in be the same on different submenus and be a single keystroke, speech synthesizer support for visually impaired SysOps, making uploads immediately shareable on Novell networks, an easy way to give a conference moderator access to all mail without having to make them SysOps, chained FMS directories, and more. PLEASE NOTE!!!!! ---- 17.3 does NOT change the structure of the user, message, or DEF files from that in 17.2. 2.4 Common Problems Encountered Installing RBBS-PC -------------------------------------------------- IT CONTINUALLY RECYCLES! This can have several causes. RBBS-PC requires that a modem be attached to your communications port. Therefore: - check what communication port is being used. - verify that this communications port exists. - verify that your modem is attached to it. - verify that your modem is powered up. - verify that your modem is configured properly. - verify that CONFIG knows what kind of modem you're using. - verify that the modem cable supports all ten signals required by RBBS-PC (see Appendix F). - verify that DTR (Data Terminal Ready) and CD (Carrier Detect) are set to "normal" rather than always "on" (sometimes called "true" and "forced" instead). - verify that each DOS subdirectory referred to in CONFIG exists. - verify that RBBS-PC runs properly when set up to use COM0 (i.e. a local workstation). If, after all of the above has been attempted, the problem still persists, try deleting your MESSAGES and USERS files and re-run CONFIG to create new ones. Finally, having exhausted all the above remedies, the system continues to continually re-cycle, you may have an incompatible "clone" PC, incompatible DOS, incompatible modem, and/or a bad copy of RBBS-PC.EXE. IT WON'T ANSWER THE PHONE! This also can be caused by one of the following things: - Phone line is not plugged into the modem. - Modem is not powered on. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-10 - Modem is not connected to the communications port that RBBS-PC was told to use. - Your modem switches or firmware is not set (see CONFIG parameter 231). - Your modem is not "Hayes compatible" enough to handle the modem commands described in section 11. - Your modem cable does not have Pin 22 connected. There are two conditions under which RBBS-PC does not require Pin 22 in the RS-232 cable to reflect the status of "ring". RBBS-PC does not require Pin 22 to be hooked up on the RS-232 cable (that's the cable which runs between the modem and the computer, by the way), if you specify in CONFIG that RBBS-PC is to answer the phone on zero rings, and that it is not a "RING-BACK" system. In this setting RBBS-PC will initialize the modem so that the modem AUTOMATICALLY answers the phone. RBBS-PC also does not require Pin 22 to reflect the status of ring when your modem returns the result code "RING" as the phone is ringing. The default setting for RBBS-PC is that it depends on either Pin 22, or the modem result code "RING", to know when the phone is ringing. This is because RBBS-PC, and NOT the modem, answers the phone. When RBBS-PC is informed by the modem that the phone is ringing, it counts the rings by issuing the "ATS1?" command. When the number of rings has reached the number you told CONFIG you wanted to answer after, RBBS-PC sends the "ATA" command to tell the modem to answer the phone (see section 11). If your modem does NOT send the characters "RING" each time the phone rings, you will need a cable with Pin 22 connected. Some computers (such as the PCjr's external RS-232 interface) and some modem cables don't have a "ring-indicator" signal. Pin 22 is the ring indicator coming from the modem going to the computer. And just because you bought an RS-232 cable, don't assume that it has Pin 22 connected. This is often not the case. IT LOCKS UP MY SYSTEM! This may be caused by one of the following things: - The .EXE file generated by the BASIC compiler is incompatible with either the DOS that you are running (i.e. it isn't IBM's PC-DOS), or other software you load into the system prior to running RBBS-PC (such as a device driver loaded in CONFIG.SYS, or a TSR program loaded in your AUTOEXEC.BAT file). Remove all non-essential memory resident software. - You indicated in CONFIG that you were running one of the supported networks (i.e. CORVUS, MultiLink, Orchid, etc.), but you aren't. - You are running on a COMPAQ DeskPro, or using an add-on board that uses the unused IBM DOS interrupt 7F hex, and should have used CONFIG parameter 29 to indicate you are using a COMPAQ PC. - Your modem isn't set up correctly, probably not supplying us with "true" carrier detect (i.e. the modem tells us that a caller is connected when that's not true). Try selecting "Hayes 2400 compatible" as the modem type in CONFIG, and use parameter 231 to re-program the modem's firmware. - RBBS-PC is trying to log to a printer that does not exist or is not turned on, or out of paper, and no error condition is ever being returned back to RBBS. In CONFIG, tell RBBS-PC to turn the printer off after each recycle (parameter 52). INSTALLING RBBS-PC 2-11 - Your system does not support standard DOS system calls for screen writes. Try setting CONFIG parameter 39 to use BASIC for screen writes. - Your system is not as PC compatible as it should be and may use strange interrupts. Try turning assembler routines off (parameter 38). "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS 3-1 3. "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS ------------------------------------------------- RBBS-PC is designed to run on an IBM Personal Computer, or compatible, running IBM's Disk Operating System (DOS), communicating via an asynchronous communications adapter (aka a "COM" or "serial" port), and using a Hayes Smartmodem, or compatible modem. The following equipment and software is the MINIMUM and the recommended configuration for running RBBS-PC: ┌────────────┬─────────────────────────────┬──────────────────────────────┐ │ Item │ Minimum │ Recommended │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │System │IBM PC or compatible │IBM AT or compatible │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │Monitor │80 column monochrome │80 column color monitor │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │COM port │RS-232 adapter with an Intel │RS-232 adapter with an Intel │ │ │8250 UART chip │16550AN UART chip │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │Modem │Any Hayes Smartmodem 1200, │A US Robotics Courier HST │ │ │or 100% compatible modem │dual standard 9600 bps modem │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │Phone line │Voice grade telephone │Voice grade telephone │ │ │connection for modem │connection for modem │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │Modem cable │25 pin RS-232 shielded cable │25 pin RS-232 shielded cable │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │RAM │512K RAM available for DOS │640K RAM available for DOS │ │ │and RBBS-PC │and RBBS-PC │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │Disk size │20MB hard disk │120MB hard disk │ ├────────────┼─────────────────────────────┼──────────────────────────────┤ │DOS version │PC-DOS version 2.1 │PC-DOS 4.01 or higher │ └────────────┴─────────────────────────────┴──────────────────────────────┘ The .EXE files are distributed with RBBS-PC as well as the BASIC source code so it is not necessary to have a BASIC Compiler to run RBBS-PC. However, for those who would like to compile RBBS-PC from the source code the recommended compiler is Microsoft's QuickBASIC version 3.0. The MINIMUM configuration that can run RBBS-PC is an IBM PC that has 320K of random access memory (RAM), one double-sided disk drive, an RS-232 communications port with a Hayes modem and IBM's PC DOS 2.0 (or higher). To run in 320K it is necessary to recompile RBBS-PC -- see Appendix U. Also if you choose to allow external file protocol transfers, an additional 192K of memory is required if you SHELL to them rather than EXIT. Beginning with RBBS-PC version 13.1A, RBBS-PC requires version 2.0 or above of IBM's Disk Operating System (DOS). RBBS-PC will not run under the BASIC interpreter. RBBS-PC runs under MS-DOS to the extent that the executable code generated by the IBM/Microsoft BASIC compiler is compatible with the multitude of different MS-DOS's. RBBS-PC is generic, but some versions of DOS do not work, such as remote drop to DOS under Tandy DOS. If you have a second telephone installed specifically for RBBS-PC, ask for a second voice grade telephone line. Data lines are very expensive and are not necessary. The program requires the use of a Hayes Smartmodem (or one that is 100% compatible) in order to function properly. If your non-Hayes modem doesn't work with RBBS-PC, send RBBS-PC (source code and all) to the RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 3-2 vendor and ask him to explain why it doesn't work, if the modem is compatible. RBBS-PC's SUPPORT POLICIES 4-1 4. RBBS-PC's SUPPORT POLICIES ----------------------------- 4.1 RBBS-PC's User Support Methods --------------------------------- RBBS-PC is supported as well as any commercial product (even better than some), albeit in a different way. Rather than a single source for technical support, RBBS-PC distributes its help via a network of volunteers. This section outlines the many ways you can find assistance in setting up your RBBS-PC Written documentation with RBBS, which you are reading. This is more a reference than a guide for novices, however. A book, "The Complete Electronic Bulletin Board Starter Kit", published by Bantam Books and available at B. Dalton Bookstores. This book covers installing RBBS-PC in detail, although the version discussed is 15.1C. (Note that RBBS-PC remains upward compatible with 15.1C, and virtually everything in the book still applies.) A commercial product, "RBBS-PC in a Box", a CD-ROM disc which has thousands of shareware and public domain programs stored in compressed format, and has RBBS-PC virtually pre-installed. You can be online only minutes after installing the CD-ROM. For information and ordering, contact Quanta Press, at (612) 641-0714. Network mail. Both RBBS-Net and RelayNet have RBBS-PC support conferences. For RBBS-Net, contract Rod Bowman (number listed below). For RelayNet contact Greg Snyder (703-323-1782, data number). Technical Support BBS. News, information, and answers to questions about RBBS-PC are available at the following numbers: (407) 627-6969 (407) 627-6862 Telephone support. When all else fails, you can place a voice call to one of the authors. Since RBBS-PC SysOps should know how to use a modem, voice calls should NOT be needed. The Technical Support BBS is a much better medium for technical questions. However, if you MUST make a voice call, dial (407) 627-9767. Usually, the phone will be answered by a voice mail system. You can record questions and call back later to hear answers. If you request that someone return your call, we will call you COLLECT. Your best chance of having a human answer the phone are between the hours of 7pm and 11pm (Eastern U.S.). Support Boards. Support boards are BBS's where the SysOp: - commits to running RBBS-PC for the foreseeable future - has an at least one free, public line - is regularly available for helping others - makes the latest version of RBBS-PC available, either electronically or by mail Please realize that bulletin boards may cease to exist, or change their phone numbers, and that other commitments can make people unavailable. Bearing that in mind, the list of BBSs knowledgeable about RBBS-PC include: Arizona Tucson: Gene Lowry, Bigfoot RBBS. (602) 886-7943 RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 4-2 California Colton: Rod Bowman, The PC Spectrum (tm). (714) 381-6013 Concord: Jon Martin, Aircomm. (415) 689-2090 LakePort: Randy Sun, Sigma Industries RBBS. (707) 263-8581 Connecticut Trumbull: Tom Mack, The Second Ring. (203) 268-5315 Florida Tampa: Dave Hacquebord, The Sunshine Board. (813) 887-3984 and (813) 885-4659 Palm Beach Gardens: Doug Azzarito, Technology Consultants RBBS. (407) 627-6969 and (407) 627-6862 Delray Beach: Mark Lautenschlager, Silicon Beach. (407) 276-6263 Kentucky Lexington: Ronald Nutter, Bluegrass RBBS. (606) 272-0499 (Fill out SysOp questionnaire) Illinois LaGrange: Loren Jones, RBBS-PC of Chicago. (708) 352-1035 Indiana Bloomington: John Taylor, Indiana On-Line. (812) 332-RBBS Maryland Rockville: Roger Fajman, CPCUG Member's Information Exchange (Capital PC Users Group). (301) 738-9060, 9 lines (Join SysOp conference) Nebraska Broken Bow: Tom Hansen, Church Chatters. (308) 872-6112 and 872-3394. Nevada Reno: John Morris, (702) 746-1364. Ohio Tiffin: Don Smith, NorthWest OHIO BBS. (419) 448-1421. Pennsylvania Sharon Hill (Philadelphia): Mark Horninger, Electric Playground. (215) 534-1466 Virginia Arlington: Lee Pollard, Death Star. (301) 839-0705 Fairfax: Ken Goosens, Your Place. (703) 978-6360, 3 lines Help by Topic: Ken Goosens maintains an interactive, on-line data base of people who volunteer to help with RBBS-PC on particular topics. Call Ken's BBS, and use the QUESTIONNAIRE function to search for someone in your area who can help. Some of the topics listed are: Auto Maintenance File Mgt System (FMS) Protocols BASIC File maintenance Questionnaires Batch Files HST Quick Basic CD-ROM Hardware Setup Communication LANTASTIC SmartText Compiling Modems Startup RBBS-PC's SUPPORT POLICIES 4-3 Conferences Network Sub-boards Configuration Novell Netware Submenus Desktop Publishing PC-Slaves Time Lock DESQview PUI Uploads Doors Personal downloads User Interface DoubleDOS Programming Utilities Most Bulletin Board Software is dedicated to making money for its authors. No matter how much the authors love the work, it endures only so long as the hope of income continues. RBBS-PC is given away for free, and depends not on the flow of money, but on the continuing dedication and generosity of people who volunteer to help support and enhance it as a public service, and share their labor of love with others for the benefit of all. The commitment of the coordinating authors of RBBS-PC is to: - fix any problems, on a priority basis - steadily refine and enhance RBBS-PC to better serve the needs of its users - help support and coordinate contributions, testing, and releases RBBS-PC should be bug free, period. If there are any problems with it, we want to know. We want people to use RBBS, not because it is free, but because it is the best bulletin board available. Professional Tech Support: While RBBS-PC remains an "all-volunteer" effort, BBSs run by corporations may find security in "paying" for support. If your corporation desires 24-hour, quick-response help, contact Doug Azzarito at (407) 627-9767. You will be referred to someone who can offer a support plan that will satisfy any corporate user. 4.2 RBBS-PC's Vendor Support Policy ----------------------------------- While a great deal of care was taken to make RBBS-PC as flexible as possible, supporting a wide range of computers and modems, the program was designed with the IBM PC (or compatible) and Hayes Smartmodem (or compatible) in mind. Many of RBBS-PC's default values assume this combination, and it is certainly this combination which requires the least effort to bring online. The philosophy of RBBS-PC is outlined in section 1.1 of the RBBS-PC documentation. Those who contribute to RBBS-PC do so without any hope of monetary reward. In fact, great lengths are taken to assure that neither those involved with the development of RBBS-PC, nor anyone who distributes RBBS-PC, does so for personal gain or to promote a specific product at the expense of other products. If the hardware you are using is not part of the "base-line" hardware and RBBS-PC doesn't work, your only recourse is to either modify RBBS-PC to meet your particular needs (that's why the source code is distributed), or contact your vendor and ask him to either fix his hardware or modify RBBS-PC (via .MRG/.DOC files) to support his hardware. Since 1984, RBBS-PC has become something of an "industry standard." As such, several manufacturers have requested that support for their RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 4-4 particular hardware and/or software be incorporated into RBBS-PC. These vendors have had three choices: 1. Obtain a copy of the BASIC source code by sending $8 to the Capital PC User Group's Software Exchange. The source code allows the vendor to determine what is required to be "RBBS-PC compatible." Who better knows the quirks of the manufacturer's product than the manufacturer? RBBS-PC's limited license specifically permits the distribution of ".MRG" files that would allow RBBS-PC to run with whatever idiomatic quirks a specific vendor's product exhibited. The advantage to the manufacturer is that they are in complete control and need not make the .MRG "universal" (i.e. it need only support their product). The disadvantage is that new releases of RBBS-PC come out every six to eight months and the vendor would have to review each release to make sure the new releases and his .MRG files were compatible. Of course, as with any other RBBS-PC operator, casual telephone support is available to these vendors. 2. Supply the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This approach has been actively DISCOURAGED for three fundamental reasons. 1. The vendor perceives he has "paid" for on-going support by the loan or donation of the product. This is not the case because RBBS-PC's development is an all-volunteer activity. As such, it is possible that none of those involved with the development of RBBS-PC may have the time or expertise sufficient to assure compatibility of the specific vendor's product with future releases of RBBS-PC. About all that can be done is to give the vendor our "best effort" to assure compatibility, and advise when it can not be made compatible. 2. The particular product may not have a universal applicability to RBBS-PC users and/or may not be of interest to those who regularly contribute to the development of RBBS-PC. Both of these conditions must exist before any vendor's product is incorporated into the RBBS-PC development cycle. 3. The price of the loaned or donated products (usually 3 to 5 such products) in no way can even begin to compensate for the hundreds (if not thousands) of development hours required to support other than "base-line" hardware. 3. Establish an on-going institutional commitment to maintain a dialogue between the vendor's engineering group and the RBBS-PC development team along with supplying the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This approach has been actively ENCOURAGED for three different and fundamental reasons. 1. The vendor overtly makes an institutional commitment to jointly participate in the development of RBBS-PC. The vendor has the opportunity to supplement the all-volunteer activity that is the basis for RBBS-PC development by choosing to either modify their current or future products to be compatible with RBBS-PC or to supply software that ensures compatibility with RBBS-PC. This benefits all RBBS-PC users. 2. The particular products that fall into this category are required to have a universal applicability to RBBS-PC users (i.e. multi-tasking DOS, networking, 2400 or greater baud capability, error-free RBBS-PC's SUPPORT POLICIES 4-5 protocols, etc.). Also, a regular contributor to RBBS-PC's development must be geographically located close to the vendor's development engineers to assure a timely dialogue. Further, any regular contributor to RBBS-PC's development who accepts the responsibility for assuring RBBS-PC's compatibility with a particular vendor's product must be willing to do so solely on a volunteer basis over an extended period of time and in such a way as not to exclude other vendor's products. Only when all these conditions exist is any vendor's product a candidate to be incorporated into the RBBS-PC development cycle. This assures that the RBBS-PC user community has a feed-back mechanism to the vendor's product development and design teams and the vendor is assured of a matching long-term commitment from the RBBS-PC development team. 3. The vendor recognizes that the price of the loaned or donated products (usually 3 to 5 such products) is minuscule compared with the hundreds (if not thousands) of man-hours that may be required from both the RBBS-PC development team as well as the vendor's engineers. This assures that the vendors who choose this third approach are committed to the PC user community. It is precisely this type of commitment that RBBS-PC's USERWARE concept is designed to encourage (from both users and vendors) Many vendors have chosen to make this third type of commitment to RBBS-PC. We hope each of them will continue their support. In turn, we hope RBBS-PC SysOps and users will show their appreciation of the vendors' support. Some of these vendors are (alphabetically): Alloy Computer Products, Inc. 165 Forest Street Marlboro, MA 01752 (508) 481-7711 Ark Electronic Products, Inc. 325 W. Hibiscus Blvd. Melbourne, Florida 32901 (407) 724-5260 Corvus Systems, Inc. 2100 Corvus Drive San Jose, California 95124 (408) 559-7000 The Forbin Project (c/o John Friel III) 4945 Colfax Avenue South Minneapolis, MN 55409 Hayes Microcomputer Products, Inc. 5923 Peachtree Industrial Blvd. Norcross, Georgia 30092 (404) 449-8791 International Business Machines Corporation (Internal Zip Code 2900) P.O. Box 1328 Boca Raton, Florida 33432 (305) 998-2000 Microcom, Inc. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 4-6 1400A Providence Highway Norwood, MA 02062 (617) 762-9310 Multi-Tech Systems, Inc. 82 Second Avenue, S.E. New Brighton, Minnesota 55112 (612) 631-3550 Orchid Technology 4790 Westinghouse Drive Fremont, CA 94539 (415) 490-8586 PC-SIG 1030 E. Duane Ave Suite D Sunnyvale, CA 94086 (408) 730-9291 Prometheus Products Incorporated 4545 Cushing Parkway Fremont, CA 94538 (415) 490-2370 Quarterdeck Office Systems 150 Pico Blvd. Santa Monica, CA 90405 (213) 392-9701 Racal-Vadic 1525 McCarthy Blvd. Milpitas, California 95035 (408) 774-0810 The Software Link, Inc. 8601 Dunwoody Place Suite 336 Atlanta, GA 30338 (404) 998-0700 System Enhancement Associates 21 New Street Wayne, NJ 07470 (201) 473-5153 U.S. Robotics, Inc. Skokie, Illinois 60076 (312) 982-5010 Users who feel that they have benefitted or who appreciate such commitment to the user community should write or call the above vendors and tell them so, especially if such a commitment influenced the purchase of their products. Similarly, if any user feels that other vendor should make a similar commitment to RBBS-PC and the user community, write to that vendor and send a copy of your letter to the following address: Ken Goosens 5020 Portsmouth Road Fairfax, VA 22032 RBBS-PC's SUPPORT POLICIES 4-7 Section 20 describes the RBBS-PC standard interface for protocol drivers. All vendors of proprietary protocols who would like to have them added to future releases of RBBS-PC need do is simply conform to this interface. HOW TO GET A COPY OF RBBS-PC SENT TO YOU 5-1 5. HOW TO GET A COPY OF RBBS-PC SENT TO YOU ------------------------------------------- RBBS-PC can be obtained by sending a check for $8 to the: Capital PC Software Exchange P.O. Box 6128 Silver Spring MD 20906. RBBS-PC is distributed on 360K diskettes, unless otherwise requested. Allow 3 to 4 weeks for delivery (remember, this is an all-volunteer effort). Be sure to specify RBBS-PC 17.3A. If you would like the RBBS-PC source code and some utilities that other SysOps have found useful, send a second $8 with your order (a total of $16). The current version of RBBS-PC can also be obtained by writing to: RBBS-PC P.O. Box 31024 Palm Beach Gardens, FL 33420-1024. Please enclose a check for $10. (U.S.), which helps pay for disks and 1st class postage (non-U.S. addresses, please enclose $15.). You will receive complete RBBS-PC program, source code, and as many RBBS-PC utilities as will fit on the media (specify 5.25" or 3.5" disks). RBBS-PC's .EXE file is distributed after having been compiled with a QuickBASIC Version 3.00 compiler which has had the DTR patch described in Appendix G applied to it. The exigencies of RBBS-PC software releases may mean that the disk you get contains an earlier version of RBBS-PC than 17.3A (either you bought the diskette sometime ago or there has been not enough time for it to be updated to this most current version). Not to fear! Your $8 has not been wasted. The support boards listed in section 4.1 should make the latest version available for downloading. You can also pre-order the next release of RBBS-PC, to be air mailed to you immediately upon release, for $25. See Appendix C for details. FILES RBBS-PC USES 6-1 6. FILES RBBS-PC USES --------------------- There are essentially two types of files that RBBS-PC uses -- "system" and "text" files. "System" files are defined as random files that RBBS-PC reads and writes to. "Text" files are defined as files that RBBS-PC primarily reads from. Text files can be edited externally to RBBS-PC with almost any text editor. Either type of file can be "static" or "variable" in length. By "static" it is meant that these files have a pre-defined length beyond which RBBS-PC does not extend them. Similarly, "variable" length files are defined as those files whose length is dynamically increased by RBBS-PC. (In some RBBS-PC environments, only the "static" length files can be shared SAFELY among multiple nodes.) The following table summarizes these files, using the default file names: "Static" Length Files "Variable" Length Files MESSAGES (can be variable) CALLERS ARCWORK?.DEF USERS COMMENTS NODE?WRK MESSAGES.BAK DOUT?.DEF RBBS?F1.DEF USERS.BAK DK*.ARC DORINFO?.DEF RBBS?PC.DEF DRST?.DEF 99.DIR (upload directory) The following "text files" are "static" in length and can be shared safely: NEWUSER RBBS-CDR.DEF MENU0 --> MENUA LG*.DEF BULLET, BULLET1 --> BULLET? AUTOPAGE.DEF DIR.DIR, aa.DIR --> bb.DIR CONFMAIL.DEF CDR.CDR, aa.CDR --> bb.CDR RBBS-CDR.DEF FILESEC PROTO.DEF CONFENCE RBBS-REG.DEF *.PUI PRELOG.DEF PASSWRDS EPILOG.DEF *.HLP PRIV.DEF HELP?? AUTOPAGE.DEF TRASHCAN RBBS?TM.DEF WELCOME MAIN.NWS In a CORVUS OmniNet network environment any of the "static" length files can be shared on a common volume and ALL of the "variable" length files must be segregated on volumes unique to each copy of RBBS-PC. RBBS-PC uses a RENAME function in order to determine if a file exists. Because of this, all the volumes accessed by any RBBS-PC in a CORVUS network must be designated "read/write." Therefore, you must be very careful when running CONFIG. CONFIG creates the definition file (RBBS?PC.DEF) for each copy of RBBS-PC. See Appendix L for information regarding Corvus OmniNet). The one file that cannot be shared is the Caller's file. RBBS-PC continually logs to it and the activity of multiple users would get mixed together. LOCKED FILE STATUS DISPLAY RBBS-PC displays the status of those files which must be locked in a network environment on line 25. The lock status of the message file is displayed in positions 68 & 69. The lock status of the user file is displayed in positions 71 & 72. The lock block status is displayed in positions 74 & 75 and comments/uploads share positions 77 & 78. The letter RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 6-2 "U" in the first position shows that the file is currently "UNLOCKED". The letter "L" in the first position indicates that the file is "LOCKED". 6.1 RBBS-PC Directory Structure ------------------------------- The RBBS-PC package contains many files, which can be put nearly anywhere the SysOp desires. However, to avoid confusion, the default locations for the RBBS-PC release files are grouped logically into subdirectories. If the files are not placed in the proper subdirectory, RBBS-PC will behave erratically until you reconfigure the file locations with CONFIG. The directory is as follows: DEFAULT DIRECTORY (usually C:\RBBS) Contains RBBS-PC program, message and user files, INSTALL files and operational .BAT files. BULLETIN DIRECTORY (usually, C:\RBBS\BULLET) Contains the RBBS-PC bulletins and bulletin menu files. FILE CATALOG DIRECTORY (usually C:\RBBS\DIR) Contains the files needed to maintain the list of files available for download. DOC DIRECTORY (usually, C:\RBBS\DOC) Contains the RBBS-PC documentation. FILE DIRECTORY (usually, C:\RBBS\FILES) Contains the files available to download. Each SysOp will want to expand this into a group of directories. Uploads may also be placed in this directory. HELP DIRECTORY (usually, C:\RBBS\HELP) Contains all online HELP files for RBBS-PC, including help files created by the SysOp. FEATURE REMOVAL DIRECTORY (usually, C:\RBBS\LIT) Contains utilities for removing features from RBBS-PC in order to reduce executable code size. MACRO DIRECTORY (usually, C:\RBBS\MACROS) Contains the MACRO files which allow the SysOp to design custom RBBS-PC commands. NODE DIRECTORY (usually, C:\RBBS\NODE1) Contains the files specific to each "node" of RBBS-PC. A multi- node system will have several "node" subdirectories. Files in this subdirectory include CALLER log files, RCTTY.BAT door interface files, and timed-event semaphore files. PERSONAL DOWNLOAD DIRECTORY (usually, C:\RBBS\PRIVATE) Contains the directory file for RBBS-PC's personal download feature. QUESTIONNAIRE DIRECTORY (usually, C:\RBBS\QUESTION) Contains the RBBS-PC questionnaire files. SMALL EXECUTABLE DIRECTORY (usually, C:\RBBS\SMF) Contains a substitute RBBS-PC.EXE which has reduced error- reporting, resulting in a smaller executable file. FILES RBBS-PC USES 6-3 SOURCE CODE DIRECTORY (usually, C:\RBBS\SOURCE) Contains source code and .BAT files for recompiling RBBS-PC. SYSTEM DIRECTORY (usually, C:\RBBS\SYSTEM) Contains configuration files used to customize RBBS-PC, such as the PASSWRDS, FILESEC, CONFMAIL and DOORS.DEF files. TEXT DIRECTORY (usually, C:\RBBS\TEXT) Contains text files seen by the callers, including MENU files, WELCOME, PRELOG and LG*.DEF. UTILITY DIRECTORY (usually, C:\RBBS\UTIL) Contains several utilities for maintaining your RBBS-PC. XFER DIRECTORY (usually, C:\RBBS\XFER) Contains the files necessary to operate file transfer protocols, including PROTO.DEF, and various protocol drivers. Before moving any of these files, be sure you are familiar with the CONFIG utility. If RBBS-PC cannot find a required file, the results are UNPREDICTABLE! The default directory structure is only offered as a guide. Each SysOp is encouraged to arrange files in a way that suits the SysOp's taste. 6.2 RBBS-PC System Files ------------------------ As shown above, "system" files are both static and variable in length. The system files used by RBBS-PC are: MESSAGES Often named MAINM.DEF. This file is a random file that contains the message text for the RBBS-PC system, and several special records (e.g. checkpoint and node records). The first record in the file contains the RBBS-PC "checkpoint" record. The records immediately following this first record are the RBBS-PC "node" records. From there, the rest of the file consists of message header records which are followed by the actual message text. Appendix A describes these records, the fields within them, and how each field is used. RBBS-PC expects the MESSAGES file to exist, and to be in the proper format (CONFIG should be used to create this file). When it loads, if CONFIG does not find the MESSAGES file, or it finds one in pre-12.3A format, CONFIG will create it and initialize it to the size the SysOp has specified. Because of the special fixed length records in this file, it should not be created or edited outside CONFIG. When the SysOp "packs" the message file using CONFIG, the current message file is preserved as MESSAGES.BAK, in case the "pack" is unsuccessful (i.e. not enough space to duplicate the message file). If the disk fills up during the pack function, RBBS-PC can recover the message file using MESSAGES.BAK. When the message file is successfully packed, the original MESSAGES file is renamed MESSAGES.OLD, and MESSAGES.BAK is renamed MESSAGES. CONFIG will ask whether you want to delete the old MESSAGES file. (Note that, in a multiple RBBS-PC environment, the message file should only be "packed" when none of the nodes are running.) The MESSAGES file can be shared among multiple RBBS-PCs. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 6-4 USERS Often named MAINU.DEF. The USERS file is a random access file that has a record for each user of the system. The record contains a profile for each user who has logged onto RBBS-PC. Appendix A describes the format of the records within the USERS file. These records are 128 bytes in length and are automatically maintained by RBBS-PC. The SysOp can do some limited editing using SysOp Function 5. RBBS-PC expects the USERS file to exist, and to be in the proper format (as the with MESSAGES file, CONFIG should be used to create this file). If CONFIG does not find the USERS file on the system when it loads, it will create it to the size specified by the SysOp. The USERS file should not be created or edited outside CONFIG (with the exception of certain utilities specifically designed for this task -- under NO circumstances use a text editor to edit the USERS file). When the SysOp "packs" the user file using CONFIG, the current USERS file is preserved as USERS.BAK, in case the "pack" is unsuccessful (i.e. not enough space to duplicate the users file). If the disk fills up during the pack function RBBS-PC will recover the USERS file from USERS.BAK. When the users file is successfully packed, the original users file is renamed USERS.OLD and the temporary file USERS.BAK is renamed USERS. CONFIG will ask whether you want to delete the old USERS file or not. (Note that in a multiple RBBS-PC environment, the USERS file should only be "packed" when none of the nodes are running.) The USERS file can be shared among multiple RBBS-PC's. CALLERS This file is a random file that contains a log of all your caller's activities as they use the system. This is an ASCII file, but it is formatted as 64 byte fixed length records with no carriage returns or line feeds between the records. If you set the "extended logging" feature of RBBS-PC to be on, then a more detailed record of each caller's activity will be kept. There are many "statistic" and "bulletin" generating utilities which have been written to work with the CALLERS file. If the CALLERS file is not found, RBBS-PC will create a new one (no need for CONFIG here). To clear the log, ERASE the file. The CALLERS file can't be shared among multiple nodes, because activity from the various nodes would be mingled together in the file, making it impossible to determine who did what, and when. ARCWORK?.DEF This file is created as output by the file view command and contains the contents of the archived file being inquired against. The node number replaces the wildcard "?". BULLET.FCK This file is used to find new bulletins when NAMED bulletins (rather than numbered bulletins) are used. It should contain a list of NAMED bulletin file names, one per line. Numbered bulletins are automatically checked by RBBS-PC. COMMENTS This file is a sequential file that contains any comments that have been left by users for the SysOp. The file can be scanned by a SysOp function, or it can be TYPEd or edited outside the RBBS-PC system. A SysOp function is available to delete this file. The file will be created by RBBS-PC if it is not found. The COMMENTS file cannot be shared among FILES RBBS-PC USES 6-5 multiple RBBS-PC's using CORVUS' "OMNINET", but can be shared using other multi-user systems. Please note that if you have activated the CONFIG parameter which tells RBBS-PC to store Comments to the SysOp as privates messages to the SysOp, then this file will not be used. DK*.ARC These files are created as output by the Library Sub-System archive program. These work files are deleted each time RBBS-PC recycles. DOORS.DEF This is the "doors control file" used by RBBS-PC to allow the SysOp more control over access to doors. See section 14.3. DORINFO?.DEF This file is created by RBBS-PC when a caller exits to a DOOR. It contains information about the caller needed by a "DOOR" (see section 14.2.2). DOUT?.DEF Used by doors to communicate back to RBBS-PC. DRST?.DEF Internal file used by RBBS-PC to restore itself upon return from doors. NODE?WRK This file is created by RBBS-PC when a caller exits to an external protocol to do "batch" downloads. It contains a list of fully qualified file names to be downloaded. QMXFER.ERR This file is created as output by QMXFER.COM to notify RBBS-PC of the results of an external file protocol transfer. RBBS?F1.DEF This is the file dynamically created when the local SysOp exits to DOS. RBBS?PC.DEF This is an ASCII text file created as output by the CONFIG program. It contains the configuration parameters for RBBS-PC. Each time RBBS-PC is run, it reads from this file. In a multiple RBBS-PC environment, the node definition file for each RBBS-PC is named RBBSxPC.DEF (where "x" is a number 1 to 9, 0 meaning the tenth node, and A through Z for the 11th through the 36th node). In a single user RBBS-PC environment, the name will be RBBS-PC.DEF. While this file CAN be edited with text editor, and many experienced RBBS-PC SysOps do this, you might have difficulty determining which parameter is which and how the various parameters work together. Unless you are QUITE SURE of what you are doing, we recommend that you use CONFIG to alter your RBBS-PC.DEF files. 99.DIR The is the default filename for the file RBBS-PC builds to hold the name, file size, date, and description appended to it of files that have been uploaded. The 99.DIR file cannot be shared among multiple RBBS-PC's using CORVUS's "OMNINET", but can be shared on other multi-user systems. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 6-6 6.3 RBBS-PC's Graphics Support ------------------------------ RBBS-PC can display three different "flavors" of text files: - Non-graphic text, consisting of the 128 ASCII characters - Graphic text, consisting of the 256-character IBM character set - ANSI color graphics, which include ANSI terminal commands to display color, position text on the screen, and play music. The "flavor" seen is based on the user's current graphics option (which can be changed with the Graphics command on the Utility menu). In order for a user to see either Graphics or ANSI color, the following items must have occurred: - The caller must have logged on with 8 bit word, no parity, and 1 stop bit. - The caller must have selected graphics (either "ASCII" or "Color-IBM"), and the file must exist with a filename ending in either: "G" For Graphic files, or "C" For ANSI Color files - The caller's hardware and software must support the "flavor" selected. All IBM PCs and compatibles support Graphics, and most will support ANSI Color, if the right device driver is loaded on the caller's system. RBBS-PC will check to see if a "graphics" file exists by appending a "G" or "C" to the file name (e.g. MAINC.NWS instead of MAIN.NWS). If such a file can't be found, RBBS-PC will check to see if a non-graphics file exists (i.e. one without the "G" or "C"). RBBS-PC will display the first file it finds. 6.4 RBBS-PC Text Files ---------------------- The RBBS-PC "text" files are both static and variable in length. The "text" files used by RBBS-PC are: AUTOPAGE.DEF This is a text file setup by the SysOp that informs RBBS-PC of which caller, callers, or group of callers that the system should automatically "page" the SysOp as soon as they log on. See section 7.11. BULLET This is a text menu file that describes the BULLETINS available on RBBS-PC. It is displayed following the WELCOME file when a user first enters the system. It must be present if CONFIG parameter 43 is greater than 1. It can also be called from the main menu with the B)ulletins command. BULLET1 --> BULLET99 There can be 1 to 99 numbered "bulletins", and virtually unlimited named bulletins. RBBS-PC will check for the existence of a file whose name consists of the prefix given by parameter 44 of CONFIG appended with the bulletin number and using parameter 41 of CONFIG to determine the drive to find the bulletin on. CONFENCE Displayed to users who issue the J)oin function from the main menu. It can be created by any text editor that can FILES RBBS-PC USES 6-7 create an ASCII file and should contain a list of the available conferences. CONFMAIL.DEF This is a text file setup by the SysOp to notify callers of the mail they have waiting in specific (or all) conferences. See section 18. DIR.DIR, *.DIR The DIR.DIR file, which can be renamed using the CONFIG utility, is a text file which contains a listing of all the categories in your FMS.DIR (FMS = File Management System, see section 12). Each of these categories has to be linked, via a code, to the entries in the FMS.DIR file, and this is done via the DIR.CAT file. If you are NOT using FMS-style directories, but rather want your file catalogs to be normal ASCII text files, then you need to create a separate file for each category listed in DIR.DIR. Each listing will be in a file *.DIR, where the wildcard "*" is the category code from DIR.DIR. The DIR.DIR file is not optional, since whether you're using FMS-style directories or not, you still need to present your list of categories to the caller. Using FMS-style directories allows you to keep all the downloadable files listed in one big file (or several smaller ones), and use category "codes" within that file to group them. Without FMS, each category code has to be its own "directory". DIR.CDR, *.CDR At least one DIR.CDR file has to be present on one of the drives available for downloading if the Library Sub-System support has been activated. Alternative directories, *.CDR should be reflected in the DIR.CDR file. EPILOG.DEF This is the default name for the questionnaire that is shown to users as they log off. It can be either an extensive "poll" (which frequent users would find tedious) or a simple thank you. Or, you omit this file entirely. FILESEC This file controls which security levels can download from which paths, and it is more fully described in section 15.4. HELP There is a help file for each command which has the format xy.HLP, where x is the first letter of the section (M,F,U) and y is the command letter, except for global and SysOp commands, which have the format y.HLP. There are also the following special help files: HELP03 Describes the message protection options when <?> is entered after the message <E>nter command is executed at the main message menu. HELP04 Describes the message entry subfunctions when <?> is entered at the subfunction prompt. HELP07 Describes the message read options when <?> is entered while reading messages. HELP09 Displayed when <H>elp is requested for the type of graphics a user wants (none, ASCII, color/music). RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 6-8 FILE.HLP Displayed when <H>elp is entered in the files subsystem function prompt. LIBR.HLP Displayed when <H>elp is entered within the library subsystem. MAIN.HLP Displayed when <H>elp is requested on the main function prompt. It contains command information. RGXPIRD.HLP Displayed to users when their registration has expired. See section 9. RGXPIRE.HLP Displayed to users when their registration is about to expire. See section 9. SECVIO.HLP If this file is present, it is shown to the caller each time a security violation occurs. SMARTTXT.HLP Illustrates the use of embedded commands within any text file displayed by RBBS-PC that causes the text to appear personalized to the caller. See section 7.9 for a more complete description of this feature. UPCAT.HLP Used to help users categorize their uploads. UTIL.HLP Displayed when <H>elp is requested in the utility subsystem function prompt. LG*.DEF This is the file displayed, if present, to users based on security level when the caller logs on. The wildcard "*" is the security level of the users who would see this file. For instance, this allows the SysOp to provide an explanation for callers whose security level falls below the minimum to log on, or it can also be used to provide a "personalized" welcome to users who have a specific security level. Some examples are: ┌─────────┬────────────┬──────────────────────────────────────────────────┐ │Security │ File name │ Sample text for level greeting file │ │ Level │ │ │ ├─────────┼────────────┼──────────────────────────────────────────────────┤ │ 9 │ LG9.DEF │ "Hi, nice to have another SysOp call in." │ ├─────────┼────────────┼──────────────────────────────────────────────────┤ │ 6 │ LG6.DEF │ "Registered users are the most appreciated." │ ├─────────┼────────────┼──────────────────────────────────────────────────┤ │ 4 │ LG4.DEF │ "Too many security violations." │ ├─────────┼────────────┼──────────────────────────────────────────────────┤ │ -1 │ LG-1.DEF │ "Your behavior has been inappropriate." │ ├─────────┼────────────┼──────────────────────────────────────────────────┤ │ -9999 │LG-9999.DEF │ Special "BBS verification" message for the U.S. │ │ │ │ BBS listing (Appendix B). │ └─────────┴────────────┴──────────────────────────────────────────────────┘ MAIN.NWS The "news" file for the main message base. If you rename your users and messages to XYZU.DEF and XYZM.DEF, then "XYZ.NWS" would be the news file. See section 7.13. FILES RBBS-PC USES 6-9 MAIN.PUI This is the programmable user interface file that allows the SysOp to structure the RBBS-PC commands as desired. See section 7.6 for a description of the PUI. MENU* These contain the local SysOp menu and menu of various commands for the subsystems. NEWUSER This is a text file that is displayed for new users just before registration occurs. PASSWRDS This file controls which security levels get which privileges, and is more fully described in section 15.3. PRELOG Displayed to callers prior to asking for their first/last name and password. PRIV.DEF This file contains the information used for "personal downloading", described in section 12.7. RBBS-CDR.DEF A text file that contains the disk numbers, paths and disk titles of disks available to the Library subsystem. The format of the file is described in section 12.6. The RBBS-CDR.DEF (and matching FMS directory) file can be downloaded from Doug Azzarito's BBS. It is not distributed with RBBS-PC because of it's size (500K). RBBS-REG.DEF This is the default name for the questionnaire that is asked of all new users who log on. The "new user" questionnaire is only seen once, by new users. This file is optional. TRASHCAN A text file that contains names that the SysOp finds objectionable and does not want used as either a users first or last name. RBBS-PC uses this file, if it exists, to deny access to anyone using one of these names for either their first or last name. WELCOME A text file that a user first sees upon logging onto the system. Similarly each "conference" can have a "welcome" file by having a file whose last character ended in a "w" (i.e. conference "RBBS" would have a message file named RBBSM.DEF and a user file named RBBSU.DEF if it where a "private" conference and a welcome file named RBBSW.DEF). PLANNING YOUR USER INTERFACE 7-1 7. PLANNING YOUR USER INTERFACE -------------------------------- RBBS-PC provides each SysOp the maximum control over what is presented to callers. There are three areas of control: - The menus presented to novice callers. - What is included in the prompt all users get. - What symbol invokes a particular function. 7.1 Menus Shown to Callers -------------------------- The menus in RBBS-PC are external text files that are presented to novice users. RBBS-PC simply displays what is in these files to the callers. Therefore, SysOps are free to change the text in these files to whatever they desire. Simply edit the files. However, be sure to use an editor that produces only ASCII text files with no special embedded characters. Most word processing editors are not suitable because they insert special symbols in the file meaningful only to it. Menus can also contain graphics and color (see section 6.3). 7.2 Subsystem Prompts Shown to Callers -------------------------------------- RBBS-PC has several configuration options which allow each SysOp to select the prompts that are presented to callers. They are: - Whether the section name is displayed. - Whether the letters of the available commands are shown. The commands in RBBS-PC are divided into four sections: MAIN, FILE, UTILITY and LIBRARY. If RBBS-PC is configured to display the section name, the command prompt will read "<section> command", otherwise "Your command". The section name is shown by default. RBBS-PC normally prompts a caller with the commands the caller has sufficient security to invoke. Each command is a single letter and is shown separated from the others by a comma. The command letters can be suppressed in the prompt. By leaving them on a SysOp provides each caller with a terse but helpful reminder of what commands are available to them. 7.3 Commands Available to Callers --------------------------------- All primary commands in RBBS-PC are invoked by single letter commands. An attempt is made to associate the command with the first letter in a word which describes the function, so that the command letter appears to be a short abbreviation for the longer word. The command to invoke reading messages is R. The default symbols that would be shown in the command line for each section are: sect |? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y 1 2 3 4 5 6 7 -----|------------------------------------------------------------------- MAIN |? @ A B C D E F H I J K O P Q R S T V W X 1 2 3 4 5 6 7 | FILE |? D G H L N P Q S U V X | UTIL |? B C E F G H L M P Q R S T U X | LIB |? A C D G H L Q S V X | GLBL |? H Q X RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-2 Four commands, ? H Q and X, have the same meaning in every section and are known as "global." The other commands all have unique function specific for the section within which they are invoked. For example, S stands for S)can messages in MAIN, S)earch in FILE and LIBRARY, and S)tatistics in UTIL. Symbols 1-7 are used for SysOp functions. RBBS-PC allows the SysOp to substitute any symbol for any command. Y)ell may be substituted for O)perator page, or Y)our mail for P)ersonal mail. If a blank is substituted, the command is removed from the list and is no longer available. 7.4 RBBS-PC's "Wrap-around" Command Search ------------------------------------------ There is an option in CONFIG which gives the SysOp unusual flexibility in configuring the user interface. A caller is always "in" a section. RBBS-PC considers the user's current section when acting on commands. The "wrap around" option allows RBBS-PC to look further for a command when it is not found in the section the caller is in. If a SysOp substitutes a blank for the V>iew conference command in the main section (as mentioned in section 7.3) and a user enters the V command from the main section, the V)iew archive file command would be what the caller would have invoked. The fundamental idea is to look further in other sections, where the search order is circular, starting at the current section, and proceeding in the following order: -MAIN->FILE->UTIL->LIBRARY->GLOBAL->SYSOP- | | -------------------<---------------------- If wrap-around is used, RBBS-PC will search ALL sections, in order, to find a valid command that matches the user's input. Even if wrap-around is not used, GLOBAL and SYSOP commands are processed globally. The important feature that wrap-around supports is that a command with a unique letter works in all sections. Thus W)ho will work everywhere if wrap-around is enabled. If every RBBS-PC command is given a unique symbol, all commands become global and there is no effective difference between sections. This allows SysOps to make commands available on a single level and makes it unnecessary to "go" to a section before using a command in that section. 7.5 How to Have a Single Universal Command Line ------------------------------------------------ The command structure within RBBS-PC can be made "flatter" without making it absolutely flat. Suppose, for example, that a SysOp wants callers to be able to do all file functions without going to a files section. In effect, the file functions are available in the main section, or the file section is merged into the main section. To do this, the SysOp must eliminate the overlap in command letters between the two sections. The main section and the file section share the letters D, P, S, and V. V is used to "view" a conference in the main section and "view" what is contained in an archived file. D is difficult because both D)oors and D)ownload are entrenched and natural options. One could leave D for the most frequently used function, say download, then use a special but arbitrary symbol like # for doors. Similarly, V could be left for viewing conference mail in the main section and a special but arbitrary symbol like & for viewing archived files in the file section. S)earch for substrings PLANNING YOUR USER INTERFACE 7-3 could be replaced by F)ind since F for going to F)iles is no longer needed. This could be accomplished by disabling F)iles and substituting F for S in the files commands. P is used for personal mail in the main section as well as personal files in the file section. Leaving P in the main section for personal mail and selecting the symbol M for personal mail in the file section would have the least impact on callers. U is used for upload. Since Quit may be used to go to UTIL, we can disable U in the main menu. We can use W for W)rite user preferences and F to find who else is on (since the F for FILES section is no longer needed). We could then revise the main menu to read: R B B S M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~ [A]nswer survey [H]elp (or ?) [P]ersonal mail [U]pload a file [B]ulletins [I]nitial welcome [$]Personal files [V]iew conference mail [C]omments [J]oin conference [Q]uit [&]View ARC files [#]DOORS [K]ill message [R]ead messsages [W]rite user pref [D]ownload [L]ist files [S]can messages [X]pert on/off [E]nter msg [N]ew files [T]opic msg scan [Z]ippy search [F]ind who's on [O]perator page [@]Library [G]oodbye Obviously the limitations of using a single section (as the more primitive bulletin board systems do) means that the number of commands must be restricted to either - 26 (letters in the alphabet), or - 36 (letters in the alphabet plus the numbers 0 through 9), or - full "words". With this artificial limitation of a single section, commands become limited in number, cryptic, or both. If the even more clumsy use of full "words" is chosen, the system must slow down as it can no longer act immediately upon seeing the first character of a command as RBBS-PC does. However, assuming that someone would actually want to configure RBBS-PC to be "flat" (i.e. have a single command line), let us continue. In order not to confuse the caller by being in a section and seeing only some of the commands we want him to use, the SysOp could elect not to show the section in the prompt (CONFIG parameter 37) and not to show the commands (CONFIG parameter 38). Callers would see simply "Your command?" as the prompt. This makes the expert mode quite terse, but that simply means users would spend more time in novice mode before using expert. Now suppose that only a single command line was desired and that the commands from the "Utilities" menu commands were to be added to the above. The "global" H, ?, Q, and X commands already are in the single command line. M for message margin can remain unchanged since it is unique to the Utilities subsystem. In order to accommodate the redundancy of letters that exist by including the Utilities subsystem's commands, the W command for the main message subsystem can be re-enabled and the remote SysOps commands be eliminated in order to re-use the numbers. The Utilities subsystem commands B, C, F, G, RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-4 L, R, and S could then be replaced by the numbers 1 through 9. The Utilities subsystem commands T, U, E, and P could be replaced by the commands <, >, \, and !, respectively. This final menu of all RBBS-PC commands could be re-written without any apparent sub-sections as follows and the screen that the would appear to the "novice" users as: R B B S C O M M A N D S ~~~~~~~~~~~~~~~~~~~~~~~~ [A]nswer survey [O]perator page [1] Change Baud Rate 300-->450 [B]ulletins [$]Personal files [2] Display time of day [C]omments [P]ersonal mail [3] Set file transfer protocol [#]DOORS [Q]uit [4] Set type of graphics mode [D]ownload [R]ead messages [5] Set page length [E]nter msg [S]can messages [8] Review callers preferences [G]oodbye [T]opic msg scan [9] Display system statistics [H]elp (or ?) [U]pload a file [<] Toggle users options on/off [I]nitial welcome [V]iew conference mail [>] Show the log of callers [J]oin conference [&]View ARC files [@] Library [K]ill message [W]ho's on other nodes [\] Change echo selection [L]ist files [X]pert on/off [!] Change password [M]argin set [Z]ippy search [N]ew files Your command? 7.6 RBBS-PC'S Programmable User Interface (PUI) ----------------------------------------------- The programmable user interface (PUI, pronounced "pee you eye") lets the SysOp take TOTAL CONTROL over what the caller is presented with, including: - the novice menu - the prompt line - the organization of commands into groups (sections) - the flow between sections - unlimited levels of nested menus. This allows the RBBS-PC interface that the caller sees to take on any appearance desired by the SysOp. In effect, the SysOp is limited only by the intrinsic functions of RBBS-PC that have been programmed into RBBS-PC source code. These functions can be assigned any command letter desired in CONFIG. PUI lets the SysOp completely control how these commands are presented to the user - allowing RBBS-PC to "emulate" virtually any other host communications environment that the SysOp's callers may be familiar with. If no PUI is provided, RBBS-PC defaults to dividing the commands into a MAIN, FILES, UTILITIES, and LIBRARY section. RBBS-PC's PUI gives each SysOp the flexibility to tailor RBBS-PC to meet special needs. In effect, RBBS-PC's PUI allows the SysOp to adjust RBBS-PC to what the SysOp wants, rather than forcing the SysOp and his callers to conform to RBBS-PC. However, unlike RBBS-PC, the PUI does not adjust the prompt to show only the commands that the user has sufficient security to do. And, of course, PUI takes much more time to design and implement. PLANNING YOUR USER INTERFACE 7-5 When the SysOp takes control of what the user is presented by using the PUI, RBBS-PC does what the SysOp has explicitly set up -- and nothing else! For example, RBBS-PC's "global" commands, like help and the expert toggle, are no longer automatically available everywhere. They are available only where the SysOp has indicated via the PUI. RBBS-PC's default user interface has evolved over the years to represent what the callers found useful (not the SysOps!). A great deal of time and thought went into RBBS-PC's default user interface, and it is easy to overlook important things when a SysOp goes about setting up his or her own. When using the PUI assume that a new user interface will take time to both develop and refine (based on your callers feedback). Designing and implementing a PUI is not a simple undertaking as it is a total replacement for RBBS-PC's standard user interface. 7.6.1 An Example Using PUI -------------------------- The main menu in RBBS-PC can represent a bewildering variety of commands, especially to a new user. Studies show that human beings can effectively deal with at most 7 choices at one time, whereas RBBS-PC has 10 more than that in its main section. To help people in this situation, the different choices in RBBS-PC are grouped into related commands, but the choices can still be overwhelming. Some SysOps have tried to simplify the main menu by breaking it up into more sections. The most tempting group of commands to spin off are the message commands. Suppose the main menu is to be simplified to look like: <F>iles <M>ail <U>ser preferences <G>oodbye The <M>ail command puts the caller in a section where commands related to messages become available in yet another menu, such as J)oin and E)nter. PUI is required because the commands are grouped into different sections. While the default menu of RBBS-PC could be edited to say this, the underlying commands would not be grouped as desired. 7.6.2 How to Implement PUI -------------------------- First, plan carefully on paper exactly what you want the caller to see and what happens with each command. Consider also, if you have a submenu, how users are to get out of it. Each menu or section of PUI is controlled by a file whose extension is "PUI". The PUI is installed by putting a "main" PUI file whose name is specified in CONFIG. The default is "MAIN.PUI". Each sub-board in RBBS-PC can have a different PUI system if desired. A PUI file consists of exactly 10 lines, and the format is: LINE CONTENTS 1 name of novice menu 2 prompt to display 3 valid commands, corresponding RBBS-PC commands 4 which valid commands are menus 5 names of PUIs that are menus 6 letter of quit command 7 prompt for quit command 8 valid sub-commands of quit command RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-6 9 which quit commands are PUIs 10 names of menu PUIs in quit command The text in the lines should NOT be enclosed in quotes, except possibly the two parts of line 3. The novice menu is just a text file displayed to novices, just like the default menus (MENU1, MENU2, etc.). The name can include a drive or path as well as an extension. The menu PUIs in lines 5 and 10 must be stored in the same drive/path as that in line 1. The prompt to display is what all callers see when asked for a choice, including experts. Normally this includes a brief listing of the commands available along with a request for a command. This prompt is NOT dynamically adjusted to reflect the security level of the caller, unlike the default prompt in RBBS-PC, which removes commands the caller cannot execute. Each PUI defines a "section" of RBBS-PC (just like RBBS-PC has main, file, library, and utility sections). The valid commands are the symbols for the acceptable commands in this PUI section. They must be upper case only. The first part is the names of the commands that the caller must give. Each symbol must be mapped to a corresponding internal symbol name in RBBS-PC which is set in CONFIG. This way the same letter in a given menu can be used for different commands in RBBS-PC, just as "S" stands for S)can messages in the main section and S)ubstring search in the files section. Since the default underlying RBBS-PC commands use the same letter in different menus, you should first reconfigure RBBS-PC to assign each RBBS-PC command a different underlying symbol. Then in the PUI file map the letter you want the caller to use to that underlying symbol. Be sure in configuration NOT to limit commands to the current section -- you must let RBBS-PC search in other sections for underlying commands when it does not find it in the current section. In addition to the normal commands available in RBBS-PC, the SysOp can include new commands which invoke other menus. These must be symbols in the list of valid commands. If a valid menu choice is picked, there must be a PUI file for that choice. Line 5 tells what prefix the PUI file has. Each PUI name must consist of exactly 7 characters. The PUI name can be shorter than 7 letters, but in the list you must blank fill out to 7 positions to the right. The first 7 characters are for the first valid menu command, the second 7 characters are for the second valid menu command, etc. RBBS-PC will automatically append the extension "PUI" to this file name. Note that all PUI files must be in the same drive/path as the novice menu in line 1. The last 5 lines in the PUI file concern how control goes from one PUI to another. The PUI processing supports a "quit to" command in which the caller can jump to other menus - which one is specified in the subcommands to the quit command (just like RBBS-PC's "quit" to command). Line 6 is the symbol (in the valid commands) which is the quit-to command. It must be a single capital letter. Line 7 is the prompt for the quit-to command, to be presented to callers after they select the quit-to command (type ahead is supported). PLANNING YOUR USER INTERFACE 7-7 Line 8 is the list of the valid sub-commands of the quit-to command. Each command must be a capital letter. Line 9 tells which of the valid subcommands are PUI commands. If a sub-command is valid but not a PUI command, control will be passed to RBBS-PC to process the quit-to command. For example, Quit-to S)ystem for hanging up would have to be processed this way. Line 10 tells what are the names of the PUI files for each PUI command in line 9. The format of the PUI names is exactly the same as in line 5 -- 7 characters blank filled to the right if shorter. The following file MAIN.PUI installs the example that was discussed in the previous section: MMENU Enter choice: <F,M,U,G> FGMU," G " FMU FMENU MAILM UMENU <5 blank lines follow> The name of the menu to be displayed initially is MMENU. The prompt users will see is "Enter choice: <F,M,U,G>?" (RBBS-PC adds the trailing "?" for prompts). The four valid commands are F, G, M, and U. Three of these commands invoke other menus (F, M, and U), and G is a non-menu command, i.e. one of the base RBBS-PC functions. The PUI file name for "F" is FMENU.PUI, MAILM.PUI for "M", and UMENU.PUI for "U". Each of these PUI files gives the same type of information as the main PUI. For example, MAILM.PUI might contain MAILM.MNU Enter choice: <E,J,P,Q,R,S,T> EJPQRST,EJPQRST Q MAIN <5 blank lines follow> The novice menu for the mail section is in file MAILM.MNU. This file might contain the following text: M A I L S U B S Y S T E M ~~~~~~~~~~~~~~~~~~~~~~~~~~~ E)nter a message J)oin a new message base P)ersonal mail (review) Q)uit to main section R)ead messages S)can msg headers T)opic msg scan The prompt will appear immediately below this line unless an extra blank line is included in the menu file. There is only one menu command: Q for getting back to the main menu. The PUI system can also be used to emulate the default RBBS-PC commands with 4 sections. Four sample files are provided for accomplishing this: XMAIN.PUI, XFILE.PUI, XUTIL.PUI, and XLIBR.PUI. For novice menus, each uses the standard default menu that comes with RBBS-PC. These require RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-8 RBBS-PC to be configured with the following symbols for the underlying RBBS-PC commands: MAIN = normal: ABCDEFIJKOPRSTUVW reconfigured: ABC>EFIJKOPRSTU\W FILES = normal: DGLNPSUV reconfigured: DGLNYZ^V UTIL = normal: BCEFGLMPRSTU reconfigured: !#E$<&M*()-+ GLOBAL = normal: H?QX reconfigured: H?QX SysOp = normal: 1234567 reconfigured: 1234567 LIBRARY =normal: ACDGLSV reconfigured: []{G}:' 7.7 RBBS-PC's Support of Sub-menus ---------------------------------- Sub-menu support means that an item on a menu can itself be another menu, so that selecting it results in a new menu being displayed from which the caller can select yet another option. The areas in RBBS-PC that can have sub-menu support include: answering surveys, bulletins, doors, joining a conference, and the file subsystem command to list directories. A primary use of sub-menus is to simplify the user interface, chiefly by allowing sub-categorization of the option. For example, suppose a SysOp has a complex system of doors, including multi-user games (TREK, NAPOLEON, 3DCHESS), single-user games (D&D, R&R, PICKUP), and demonstrations (DBIII, ORACLE, ADVENT). These could be presented on a single menu, such as: The following Doors are available: Multi-User Games TREK - explore the galaxy, compete with 12 other players NAPOLEON - be Russia, Italy, or England and fight the computer 3DCHESS - are you ready, Spock? Single-User Games D&D - the Unix dungeons and dragons! R&R - welcome to Taipei, Tokyo, or Bangkok, soldier! PICKUP - do you have what it takes? Demos - all self running DBIII - Special version of DB3 adopted for remote usage ORACLE - see the power of SQL. Full screen if you emulate ANSI. ADVENT - our own home brewed ... With sub-menus, the user could see a single, 3 item menu Doors are available for: MGAME - multi-user games SGAME - single-user games PLANNING YOUR USER INTERFACE 7-9 DEMO - self running demos When the caller picks one of these three, a new menu comes up that lists the particular doors for each category. For example, after picking MGAME the caller sees Multi-User Games available include: TREK - explore the galaxy, compete with 12 other players NAPOLEON - be Russia, Italy, or England and fight the computer 3DCHESS - are you ready, Spock? RBBS-PC's sub-menu capabilities allow SysOps to set up "tree-structured", "key word" paths to options. Bulletins provide an example where this type of structure can be very useful. Bulletins have two main uses: short, system-wide announcements, and a standard stock of text files for policies and procedures for a RBBS-PC. Some SysOps, however, have wanted to put up an elaborate system of announcements, where in fact these "bulletins" are a featured way of presenting data to callers. For example, an association published 300 short pamphlets under a dozen categories, and wants to make this information available on-line. Sub-menus fit this need very well. The main bulletin menu could read: Bulletins are available for: NURSES - nurses OB - obstetricians PED - pediatricians FAM - family physicians Please type in the category you want: OB, instead of being a bulletin, is a sub-menu that displays: The following bulletins are available for OBSTETRICIANS. Each entry shows the length and price per glossy copy. NAT - natural childbirth, 8 pages, $3 MIDW - midwives. 20 p., $5 NUTRI - special nutritional needs of pregnant women, 25p, $6 FPLAN - family planning services, 40 p, $3 DRUG - drugs to beware when pregnant, 50 p., $5 When the caller picks MIDW, the associated document is displayed. In this example, bulletins become a menu-driven way of selecting documents to browse. In order for the previous example to work, RBBS-PC utilizes "named" bulletins. For example, selecting "B" as the bulletin prefix, the above bulletins would be files BNAT, BMIDW, BNUTRI, BFLAN, and BDRUG. However, RBBS-PC's "new bulletin search" function will only search for named bulletins if they are listed in the file x.FCK (where x is the bulletin prefix). Also, named bulletins are not listed in the "new" bulletin list as numbered bulletins are. 7.7.1 How to Implement Sub-menus -------------------------------- If "XXX" is an option on a menu, simply create a file named "XXX.MNU" that has in it the text for the menu. Put this file in the same drive/path as RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-10 the non-menu options (e.g. where the "BAT" files go for doors, where the bulletin files to display are put, where the directory files are). For example, if "B" is the bulletin prefix, the above example would be implemented by adding the files "BNURSE.MNU", "BOB.MNU", "BPED.MNU", and "BFAM.MNU". Put these files on the same drive that the bulletins themselves go. The .MNU extension alerts RBBS-PC to the fact that the file is a menu. Thus, RBBS-PC will only LIST the menu file, rather than ACT on it (e.g. 3DCHESS.BAT is a door to be run, while 3DCHESS.MNU is a menu to be listed). 7.7.2 Shared Options Across Sub-menus ------------------------------------- RBBS-PC supports identical choices from different sub-menus. E.g. the main menu has sub-menus A and B, and BOTH of these sub-menus could have an option X on them, which triggered a different action (based on which sub- menu it X was selected from). The way that this works is RBBS-PC searches both for the global prefix and the user response as well as looking for the current prefix and user response. If the bulletin prefix is "B", and the structure of bulletins is as follows: / 1 BM is main bulletin menu, B is the prefix A ---- 2 BMA.MNU submenu get with choice A / \ 3 BMB.MNU submenu get with choice B / BMC.MNU submenu get with choice C / / 1 BM --- B ---- 2 BMA1, BMA2, BMA3 bulletins active at BA \ \ 3 BMB1, BMB2, BMB3 bulletins active at BB \ BMC1, BMC2, BMC3 bulletins active at BC \ / 1 C ---- 2 \ 3 7.8 RBBS-PC's "Macro" Command Support ------------------------------------- RBBS-PC's "macro" support expands a single keystroke into multiple keystrokes. It allows RBBS-PC to be tailored in even a greater variety of ways than before because a single command can be set up to invoke a sequence of multiple RBBS-PC commands. The concept is similar to the keyboard macro function found in many terminal emulators, except that in RBBS-PC the SysOp defines the macros and the caller invokes them transparently without knowing. Macros add a new dimension to RBBS-PC commands -- commands can be a full word rather than just a single letter. A macro is invoked by a name up to 8 characters. For example, "DOOR" and "OPEN" can be used to invoke doors. This makes it easy to make all commands available on a single level, since D could trigger a download, while the word DOOR will trigger the door function. Macros can be used to abbreviate a longer series of commands. If the SysOp wants to use "A)bandon conference", all that need be done is to add a macro called "A" whose content is "J M" (join main). Or if N)etmail is to be used to read Fido-net compatible message bases, a macro called "N" could be set up as "D NETMAIL" (use door called NETMAIL). RBBS-PC thus can have UNLIMITED commands. A string of RBBS-PC commands can be stored in a macro for many different types of purposes, including (but not limited to): PLANNING YOUR USER INTERFACE 7-11 setting up demos, showing a user what to do rather than just explaining it in words, automated testing of RBBS-PC features Macros can also be used to make the same type of function do different work. For example, the B)ulletin command basically displays a text file. Suppose an association wants to let persons order pamphlets and preview them on-line. Rather than bury the ordering function insider A)nswer questionnaire and the preview function inside B)ulletins, the commands PREVIEW and ORDER can be added as macros, where ORDER stands for "A ORDWHAT" AND "ORDWHAT" is a submenu listing what can be ordered. Each option on the submenu is a questionnaire. PREVIEW similarly is "B PREWHAT" where "PREWHAT" is a submenu listing the available pamphlets that are stored as text files. Macros can be built to provide interactive help to callers. For example, you can put up a macro called EZDOWN to help people download. It explains everything, asks for the file name and protocol, and tells the caller what they should be doing on their end, and then drives the download. Macros can be used to provide integrated data bases. Unlike questionnaires, you can totally control how data is written to a file. You can put in labels, or data only, put the values in quotes, separate the values by commas, etc. This is done by creating a template into which data values are written. Macros can be used to give "tours" of your RBBS-PC -- to showcase new or special features. Macros can be controlled via security level access, just like regular commands, and they can be forced to operate only in certain contexts. Macros can be - invoked anywhere within RBBS-PC -- including questionnaires, - unlimited in length, - used even when the caller has "turbo" key feature enabled, - used with SmartText (see section 7.9), - used to store responses that can be manipulated later, and - used to support graphics versions of text. It is important to remember that a macro will be ignored if its name is the same as any command. To replace a command with a macro, you must insure that the letter for the command has been reassigned. CONFIG parameters 30-34 allow such reassignments to be easily accomplished. Some contexts will not accept macros, such as when RBBS-PC prompts for a search string. Macro commands with more than one letter override all others. This means that the macro interpretation will prevail if more than one interpretation is possible. For example, in the absence of macros the command "door" would the interpreted as the command "d", so that saying "door" in the files section would be download. But a "DOOR.MCR" would be executed instead when it exists. One letter commands, however, will be executed when they match a command letter, and so any macros will be ignored that have the same one letter name the same as a command. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-12 7.8.1 How to Set Up "Macros" ---------------------------- To use macros, two CONFIG parameters must be specified: the drive/path where macro files are stored (CONFIG parameter 79) and the extension the macro files will have (CONFIG parameter 80). The defaults are "C:" and "MCR". To create a macro named X, simply create a file with prefix X and the macro extension and place in it the macro drive/path. If you are not using any macros, RBBS-PC will run faster if you specify NO macro extension in CONFIG parameter 80. The first line within a "macro" controls access to the macro, both by security level, and a limitation on the scope of the macro, in which it will be operative, including - anywhere inside a section - anywhere inside a command - only at a section and not inside. The format of the first line is: <SecLevel>/<constraint> where <SecLevel> is the minimum security required to run the macro, and <constraint> is the section (M for main, F for file, U for utility, or @ for library) and command letter the macro is confined to (use original command letter, not the reassigned ones). For example 4/M means that security level 4 is required, and the macro runs only at or inside the main section prompt. 5/MB means that security level 5 is required and the macro runs only at or inside the main section bulletin command. Thus the macro file 1.mcr 2/MJ {EN RBBS means that when inside the main J)oin, the text "RBBS" will be substituted for "1". (So "J 1" does the work of "J RBBS".) The "{EN" means not to echo what the macro substitutes (user does not see "RBBS"). To make a macro operative only at a section prompt and not inside, add a " /" to the end of the section constraint. For example, 4/M / means that the macro applies only at the main section prompt. For example, the macro SP.MCR 4/M / {EN J SEMIPRV will substitute "J SEMIPRV" for "SP" when at the main prompt, but NOT for "SP" inside the message read command ("R SP L"). PLANNING YOUR USER INTERFACE 7-13 Note: a macro will be ignored if its name is the same as a command symbol. To use 1, 2, 3, etc. for macro commands, you must disable or substitute other symbols for the SysOp commands. The first line of a macro must be the minimum security level to use the macro. The macro will simply be ignored if the caller has insufficient security. The second line will be parsed and replace the macro name. The remaining lines will be read from disk and processed as required. Macro commands have the same structure as SmartText variables: <command prefix><command name> where <command prefix> is the SmartText command specified in CONFIG. The symbol "{" (ASCII 123) is the default. The <command name> consists of two characters. Lines that are not valid macro commands are simply passed to RBBS-PC as if the user had typed them in. There are three differences between SmartText variables and macro commands: (1) Macro commands must be the first three characters on a line, whereas SmartText variables can occur anywhere on a line. (2) Macro commands can have an argument after the command name, and( (3) A macro command can apply to a block of lines following it. 7.8.2 Macro Commands -------------------- RBBS-PC "Macro" Commands include the capability of having commands executed within the "macro" rather than simply passing keystrokes to RBBS-PC. In all prompts and blocks, substitution is supported for both stored answers SmartText variables. The following is a list and description of valid "macro" commands: *0 - display what follows on the line with no carriage return. *1 - display what follows on the line with a carriage return. *B - display what follows on subsequent lines. *F - display the named file that follows. nn - display a prompt and store result in work variable nn. WT - pause for the number of seconds specified after "WT". >> - append the following block of text to the file specified. ST - Stack the characters immediately following the "ST". M! - Execute the named macro that follows on the same line. ON - Case logic for branching within macros based on stored results. EY - Echo the text passed in macros as keystrokes. EN - Do not echo the macro keystrokes. << - Display fields from a file in a form. := - Assign value to a work variable LV - Verify that answer of one in a list NV - Verify that answer is between two integers CV - Verify that answer is between two character values LO - Set location for Fast File Searches for download, upload, view The syntax and an example of each command follows: *0 - display what follows on the line with no carriage return. {*0Press any key to continue RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-14 *1 - display what follows on the line with a carriage return. {*1{FN, I hope you enjoyed your tour of the board! The caller's first name is substituted for the SmartText variable "{FN." *B - display what follows on subsequent lines, each line with a carriage return, up to the line beginning with "{END". {*B This is an example of a macro's ability to display multiple lines. The macro command is {*B and it will display all lines until it encounters one beginning with {END. Like it, {FN? {END The caller will seen everything between the first and last lines, with the first name substituted into the last line displayed. *F - display the named file that follows. {*F L:\RBBS\HELP.LST will display the file HELP.LST. nn - use the text that follows on the line as a prompt and store the answer in an internal working variable numbered nn. nn must be two digits and can be 01, 02, 03, ..., 99. CONFIG parameter 94 controls the maximum # of work variables. {01Please enter the Department you work for: {02Please enter your Office number: This will store the answers in work variable # 1 and 2, which can be subsequently referenced as "[1]" and "[2]". You can have as many work variables as specified in CONFIG parameter 94. Variables that are reused have their values overwritten. WT - pause for the number of seconds specified after "WT". {WT 2 will wait for 2 seconds. >> - append the following block of text to the file specified on this line. {>> C:MACRO.DAT "{FN","{LN","[1]","[2]" {END will append the following line to the file named MACRO.DAT on drive C:, assuming the caller is KEN GOOSENS, and he responded to the above prompts for Department with "Controller" and Office # with "107". Then the line what would be written out is: "KEN","GOOSENS","Controller","107" PLANNING YOUR USER INTERFACE 7-15 As many lines can be included as desired. Simply end the block to be written out with "{END" as the beginning of the line. Some data base managers want fixed length files and this is possible in the macro append. Just add "/FL" on the macro command line. Rather than replace, the substitution will overlay the line at the "[", thus keeping the output fixed length. Lets suppose that the first work variable has "A" as a value, the second work variable has the value "123456", the third work variable has "Henry" as a value, and the caller's first name is KEN. Then {>> C:\RBBS\DAT.FIL /FL [1][2]....[3]...............{FN........ {END would add the following line into DAT.FIL A 123456.Henry.............KEN......... Normally, blanks would be put where dots are show. ST - Stack the characters immediately following the "ST". {ST will stack a carriage return (no characters). And {STD [1] [2] would stack "D RBBS-EXE.ARC Z" - as if they were typed and ENTER pressed - if the first work variable had "RBBS-PC.EXE" and the second work variable held "Z". It is important to note that "macros" are so transparent to RBBS-PC that if you use macros to display text at an RBBS-PC prompt like "Enter command? ", RBBS-PC will continue to sit there waiting for an answer. A stacked carriage return at the end will cause the prompt to be redisplayed, though the effect of the stack will vary with the particular prompt. M! - Execute the named macro that follows on the same line. E.g. {M! ORDER will execute the macro called ORDER. RBBS-PC does NOT return to the invoking macro when the named macro is complete. Also, The full file name of the macro to execute is not here used (i.e. ORDER.MCR), only the file prefix -- ORDER. As is shown in the example of the ON command, the macro name can have a drive/path and/or extension. If only a prefix is put in, RBBS-PC will automatically add the drive/path and extension for macros specified in CONFIG parameter 79 and parameter 80. Putting in a drive/path/extension that is different from CONFIG's assures that no caller can invoke the macro -- it only can be used internally by your application. ON - Case logic for macros. This allows responses to be tested against and branching logic developed within a "macro". An example would be: {ON 1 RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-16 {==A {M! D:\HIDDEN\CHOICEA.MCR {==B {*1You have selected option B {02Why did you select B? {==C {M! D:\HIDDEN\CHOICEA.MCR {END ON EY - Echo the text passed in macros as if keystrokes. The default is to echo. EN - Do not echo the macro keystrokes. An example would be: {EN {*1 The following commands will be executed but now shown {01 Press Enter when ready R L A {EY {*1 now you will see the responses to the prompts {01 Press Enter when ready R L A << - Display fields from a file in a form. This is one of the most powerful macro commands. It allows data to be stored in compact, data format but retrieved into a form for display to a caller. There are 5 parameters that can follow the macro command: <file name> <file format> <data#> <submode> <rec-pause> where: "<file name>" is the name of the data file that has records to read, "<file format>" is "/V" if data is stored in variable length format and "/F" if fixed length format, "<data#>" is the number of separate fields in a record for variable length data and the length of the data if fixed length, "<submode>" is the mode used to substitute data in the following form "/FL" if the form is fixed length, meaning that data is overlaid into the form so as not to change any lengths. "<rec-pause>" should be "/1" if you want to pause after each record rather than when the screen fills. An example of a "macro" that uses this capability is as follows: {*1 -TOPIC- - DATA # - - VOICE # - -First Name- -Last Name- {<< C:\RBBS\RHLP.DAT /V 5 /FL [1] [2] [3] [5] [4] {END Note that spaces occur after the "[4]". If the file RHLP.DAT contains "DOORS","703-978-6360","0","Ken","Goosens" PLANNING YOUR USER INTERFACE 7-17 "PROTOCOLS","407-627-6969","407-627-9767","Doug","Azzarito" then the caller would see -TOPIC- - DATA # - - VOICE # - -First Name- -Last Name- DOORS 703-978-6360 0 Ken Goosens PROTOCOLS 407-627-6969 407-627-9767 Doug Azzarito The same example using fixed length data would be {*1 -TOPIC- - DATA # - - VOICE # - - Name - {<< C:\RBBS\RFLH.DAT /F 69 /FL [1](34:12) [1](46:12) [1](58:12) [1](1:33) {END where RFLH.DAT contains: Ken Goosens DOORS 703-978-63600 Doug Azzarito PROTOCOLS 407-627-6969407-627-9767 This would produce the following for the caller: -TOPIC- - DATA # - - VOICE # - - Name - DOORS 703-978-6360 0 Ken Goosens PROTOCOLS 407-627-6969 407-627-9767 Doug Azzarito Note that work fields support sub-field references in the format: [n](x:y) where n is the work field number, "x" is the beginning column, and "y" is the # of bytes to get. If work field two had a value "123abcde" then "[2](3:4)" would have "3abc" as its value. Fixed length records are always referenced as work variable one. := - Assign a value to a work variable. Work variables can be assigned a value inside a macro. The command to do this is ":=". E.g. {:= 5 OK assigns string "OK" to work variable 5. LV, NV, and CV - Macros can edit the responses to questions. Edits can constrain the answer to - one of a list - a numeric value between two values - a character value between two values An editing constraint must be put in front of the actual macro question it applies to, and a constraint applies only to the next question and does not remain operative. The commands for these are respectively "LV" (List Verify), "NV" (Numeric Verify), and "CV" (Character Verify). The list verify uses the first character after the command as a delimiter between valid responses. E.g. "{LV;R;A;E;" means that only "R", "A", and "E" will be accepted as answers ("{LV/R/A/E/" would have the same effect). RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-18 Semi-colon is the best delimiter in general because it cannot be entered as a value. Numeric and Character verify check inclusive ranges. Thus "{NV 7 11" will accept 7, 8, 9, 10, or 11. The numeric value must be an integer between -32,768 and 32,767. To accept answers B through E, the macro edit command is "{CV B E". Whenever an answer fails an edit, the message "Invalid answer <...>" is given with the answer received between brackets, and the question is asked again. An example of a macro with edits is: 4 {*1 Verification macro {*1 now checking list... {LV;A;F;W; {01 Enter A, F, or W {*1 now testing numeric range... {NV 5 15 {01 Enter a number between 5 and 15 {*1 now testing character range... {CV D J {01 Enter a character between D and J LO - Sets location that a file is to be searched for in an upload, download, or view request. Followed by a drive path. Useful when want to have a macro execute in front of a download or upload for a file which is really available (see section 12.9). Applies only to Fast File Search. For example, {LO F:\DF1\ would set the file location to drive F subdirectory DF1. 7.8.3 A Sample Macro -------------------- Suppose A)bandon conference is to be implemented in RBBS-PC. To do this, the command A)nswer questionnaires must be assigned a different letter. Else A will always invoke answer instead. Then the macro file could contain 5 J M The command "A" will then be followed by "Rejoining MAIN". Incidentally, if the macro had been implemented by 5 J M The only difference is that the prompt for what conference to join will be displayed, "M" then would be displayed as if the caller had typed it, and then main would be rejoined. The difference is caused by the fact that the first line after the security level is what replaces the macro name, so in the first case "M" preempts the prompt but not in the second. PLANNING YOUR USER INTERFACE 7-19 7.8.4 On-line Data Base With Macros & Questionnaires ---------------------------------------------------- RBBS-PC provides the SysOp with the ability to offer callers access to an on-line database both internally (using macros and questionnaires) and externally to RBBS-PC (see Appendix R). RBBS-PC's internal Remote Data Base feature gives the SysOp the ability to: - set up unlimited numbers of named data bases - set up menus to interact with the user - prompt users for data - use Metavariables - both work variables and SmartText variables. - store user's answers in work variables. Any subfield in a work variable can be referenced. - display, or store all metavariables - process commands conditionally - save Metavariables to file through templates, allowing data to be stored in virtually any format desired - retrieve data into templates for display. - do full screen data entry RBBS-PC's support for "full screen" questionnaires and macros takes some work on the SysOp's part. The SysOp must use ANSI screen commands. The SysOp must then arrange to transmit the "template" that clears the callers screen and writes the appropriate static text (lines, labels, etc.) on the callers screen. Then the data the user is to see is transmitted onto the caller's screen. The "full screen" support does not allow the caller to use keys like tab and cursor arrows to move around on the screen. It is "full screen" in the sense that the caller sees all the data that is to be entered and the cursor moves from field to field. On-line Database Example ------------------------ This application manages a data base of callers who are willing to help with RBBS-PC by topic. It is controlled at a high level by the following questionnaire. C:DUMMY.DAT,4 * This questionnaire is for finding help with RBBS-PC by topic. * Please register yourself if you * - are willing to help others, and * - know enough about a topic to help * * Examples of topics people need help with: * Desqview Modem models (HST, Everex, USR Internal, etc.) * PC-Slaves Protocols Conferences FMS * Doors DoubleDos Sub-boards PUI * Questionnaires 10-Net Macros Uploads * MU-Purge File maint. Personal dnld Caller Analysis * :-[prompt]- T ? V)iew database, E)nter new data, Q)uit (V,A,Q) =V-[view]-=E-[add]-=Q-[quit]-= -[prompt]- :-[view]- M C:\RBBS\VIEWHELP.MCR >-[prompt]- :-[quit]- @ RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-20 :-[add]- * 703-978-6360 ?1 BBS data number * 703-978-4339 ?2 Voice # (evening, 0 not to give) * You can specify as many topics as desired, one at a time. * :-[topic]- ?3 RBBS-PC topic you will help others with, or Q)uit =Q-[prompt]-= -[addrec]- :-[addrec]- * -Topic- - Data # - - Voice # - Last Name First Name */FL[3] [1] [2] {LN {FN T ?Really add this record (Y,N) =Y-[really]-=N-[topic]-= -[addrec]- :-[really]- M C:\RBBS\ADDHELP.MCR >-[topic]- Two macros are used by this questionnaire: VIEWHELP.MCR for displaying the data base, and ADDHELP.MCR for appending new data to the data base. VIEWHELP.MCR contains 5 {*1 -Topic- - Data # - - Voice # - Last Name First Name {*F RBBSHELP.DAT ADDHELP.MCR contains 5 {>> RBBSHELP.DAT /FL [3] [1] [2] {LN {FN {END Full Screen Example Full screen is available only in a color graphics version of questionnaires and macros. A long application for collecting BBS information is given in these following files: REGRBBS.DEF - Questionnaire driver, TTY version REGRBBSC.DEF - Color graphics version of questionnaire driver VUNRBBS.MCR - View data base macro, TTY version VUNRBBSC.MCR - View data base macro, Color graphics version SVRBBS.MCR - Macro to save data to a comma separated data file These files can generally be download from most bulletin board systems. However, they are definitely available on Ken Goosens' RBBS-PC system at (703) 978-6360. Hints for Building Remote Data Base Applications ------------------------------------------------ Generally you will have: PLANNING YOUR USER INTERFACE 7-21 - a questionnaire driver that gives caller option to exit, view database, or Enter new data - a macro to retrieve data from file to a form - a macro to save data in a data base format - a data entry routine in the questionnaire. Creating a "full-screen" application is more complicated that than a line- at-a-time (i.e. TTY) application. For full-screen applications, you will want to: - paint a template with everything but the data values, such as row and column labels and titles. - clear out the existing values in a form and then put in the new values. Only the changes to the screen are transmitted rather than retransmitting the entire screen when only a part changes. ANSI commands are used to control the screen. Where [ESC] stands for the one-character Escape (ASCII 27), the most useful ANSI commands to know are: [ESC][2J - clear the screen. [ESC][K - clear from current cursor position to end of line. Cursor position after clearing is same as before. [ESC][X;Yf - position the cursor on row x and column Y. E.g. "[ESC][5;10f" positions on column 10 of row 5. Case is significant in ANSI commands, so beware that "[ESC][k" will NOT clear to end of line, and "[ESC][1;7F" will not position the cursor. You can use ANSI commands to set color and blink characters. An easy way consistent with RBBS-PC is to set colors using the SmartText variables C0, C1, ..., C4, where 1-4 are the colors set in CONFIG parameter 323, parameter 324, parameter 325, and parameter 326. C0 is "emphasis off," and restores normal text color preference of the caller. An example that clears the screen, sets color to 1, positions on line 1, column 15, prints "-Sample Title-", sets color to caller's text preference, prints 2 spaces, and then prints value of work variable 1 is as follows: [ESC][2J{C1[ESC]1;15f-Sample Title-{C0 [1] 7.9 RBBS-PC's "SmartText" Variables ----------------------------------- SmartText allows the SysOp to substitute pre-defined variables in text files as menus, bulletins, help, welcome files, as well as macros and questionnaires. This allows the SysOp to present to each caller an interface that is not only "programmable", as discussed in section 7.6, but also tailored to the specific caller. Some applications for SmartText include: addressing the caller by name, as well as referring customized variables for the caller, such as city/state. For example, the welcome file could say, "Hi, <first name>, how's the weather in <city/state>?". SmartText variables can also be used for status line reports in menus, showing such things as security, minutes remaining, and current time. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-22 To utilize RBBS-PC's SmartText files, CONFIG parameter 17 must be set to the decimal value of a delineation character that the text editor used by the SysOp can handle. The character you select should have three characteristics: 1. It should be visible on the screen and when printed. This allows the SysOp to see where the control sequence is when designing the text files to be used as SmartText files. 2. It should not be a character that might be used for any other purpose in the text files. The character can still be used in text files, but the chances are slight that RBBS-PC will interpret the character as a SmartText sequence. 3. It should not be a character that might be interpreted, when printed, as being a printer command (i.e. start double spacing). IMPORTANT: While RBBS-PC currently allows you to select the SmartText character, we STRONGLY suggest you use the default character (the { character, decimal 123). Future versions of RBBS-PC will no doubt rely heavily on standard SmartText, and as such will probably NO LONGER allow you to change this character. CONFIG parameter 17 can have any value between 0 and 255. If 0 is selected, RBBS-PC's SmartText capability will be turned off. A RBBS-PC SmartText control sequence consists of the control character that was selected in CONFIG parameter 17 followed by a SmartText double- character command. These SmartText double-character commands MUST be entered as upper case characters! There are two kinds of SmartText variables: those which substitute text, and others which control how substitution is done. The commands are: COMMAND NAME MEANING BD "Bytes Downloaded" Displays the bytes downloaded today. BN "BBS Name" Displays the name of the BBS. CS "Clear Screen" Overrides RBBS-PC's automatic screen depth management so that the next "Press Enter to Continue" will not come halfway through a page. CT "City/state" Displays the caller's city & state. C0 "Color 0" Resets color to the user's selection for text. C1 "Color 1" Changes color to the user's selection for Foreground Color One. C2 "Color 2" Changes color to the user's selection for Foreground Color Two. C3 "Color 3" Changes color to the user's selection for Foreground Color Three. C4 "Color 4" Changes color to the user's selection for Foreground Color Four. DB "Dnld (tot) Bytes" Inserts the total number of bytes ever downloaded by the caller. DD "Downloads Today" Inserts the total number of files downloaded by the caller today. DL "DownLoads" Inserts the total number of files ever downloaded by the caller. DT "Date" Inserts the current date, MM-DD-YYYY, into the text file. PLANNING YOUR USER INTERFACE 7-23 FI "FileName" Inserts current work Filename into the text file FN "First Name" Inserts the user's FIRST NAME into the text file. FS "First Name SySop" Inserts the SysOp's FIRST NAME into the text file. LN "Last Name" Inserts the user's LAST NAME into the text file. LS "Last Name SysOp" Inserts the SysOp's LAST NAME into the text file. ND "Node Number" Inserts the RBBS-PC Node Number for this node. NS "Non Stop" This causes the rest of the current file to be displayed in RBBS-PC's "none stop" mode. Page breaks will be ignored following a NS command. PB "Page Break" Causes RBBS-PC page break message, "MORE (Y/N/NS/A)" or the "PRESS ENTER.." prompt to appear after the line is printed. RP "Reg Period" Inserts the number of days in the registration period. RR "Reg Remaining" Displays the days remaining in the caller's registration period. SL "Security Level" Inserts the user's current security level into the text file. TE "Time Elapsed" Inserts the user's elapsed session time (hh:mm) into the text file. TM "Time" Inserts the time (hh:mm AM/PM) into the text file. TN "Trim NO" Substitute as is (the default) TY "Trim YES" Remove leading and trailing spaces first Note: a setting for trimming remains in effect until another trim command is encountered. TR "Time Remaining" Inserts the number of minutes left in the user's session into the text file. UB "Upload Bytes" Displays the total number of bytes ever uploaded by the user. UL "UpLoads" Displays the total number of file ever uploaded by the user. VN "Overlay NO" Insert into the text file (the default). VY "Overlay YES" Overlay into the text file (do not change length) Note: an overlay setting remains in effect until explicitly replaced. When designing SmartText files, each SysOp should take into account that the some of the SmartText commands (i.e. the user's name) may significantly extend the length of a line. It is important that this line elongation be taken into consideration so that, when the actual text substitution occurs, the line seen by the caller does not exceed 80 characters. What follows is an example of a SmartText file that demonstrates how all of the above commands might be used. The following example assumes that CONFIG parameter 17 has been set to the decimal value 123 for the SmartText delineation character -- {. Introducing...{C1SmartText!{C0 RBBS-PC allows the SysOp to customize the text seen by each caller. For instance, if the SysOp wanted to make sure this message didn't scroll off the screen, he could pause the display like this: {PB Or, the SysOp may want to show the caller that today's date is {DT and the time is {TM. The SysOp may even want to include a personal greeting to {FN {LN. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-24 The SysOp can tell the caller that their security level is {SL and that they have been on-line for {TE, and have {TR minutes left in this session. This kind of capability illustrates RBBS-PC's on-going commitment to nurturing each SysOp's creativity and avoiding the dogmatic. 7.10 "Colorizing" the RBBS-PC User Interface -------------------------------------------- "Colorization" refers to the utilization of color within RBBS-PC text files and prompts. RBBS-PC has long supported graphics versions of external text files, and is even distributed with graphics menus. RBBS-PC supports "colorization" as follows: 1) In files shown to the callers including: All menus, All bulletins, The Welcome file, The file for new users, All on-line help files, Standard file directories, and FMS file directories (see item 6 below). 2) Via highlighted text in searches of messages, in searches of files, in announcing new personal mail waiting, for locked out users, and the SysOp user maintenance (function 5). Highlighting supports a limited but extremely functional use of colorization - to make it easy for the caller to spot significant bits of text on a screen. 3) Within the Programmable user interface (PUI). The PUI file can have graphics versions just like text files. The file XMAIN.PUI that was used in the example in section 7.6.2 can have a graphic's equivalent named XMAING.PUI and a color equivalent named XMAINC.PUI. Color codes can be embedded in the prompts in the PUI as well as external text files. Each SysOp has total freedom to colorize prompts as well as menus. 4) Within text internal to RBBS-PC. This applies to standard (non-PUI) prompts, such as the main command prompt, and to formatted reports, like the message scan and message read. This type of "colorization" is controlled by whether highlighting has been turned on in CONFIG. 5) Within RBBS-PC's "short" prompts. Caller foreground color 4 is used to mark the commands the user can type. Emphasis is used to mark the default selection. This colorization is based on a scan of the text to be printed: [...] : will be highlighted (default answer) (xxx) : will be put in foreground color 4 (text to type in): if xxx is not longer than 2 characters and is in caps <...> : will be put in foreground color 4 (collective choices) and if there are words before this, the first will use foreground 1 and the second, foreground 2. PLANNING YOUR USER INTERFACE 7-25 "Short" prompts colorization applies to ALL text displayed by RBBS-PC before an answer is expected. For example, by using the above conventions, questionnaires can be colorized. This is controlled by whether highlighting is on. 6) Within FMS file directories. The "colorization" of the FMS file directories is based on the four colors specified in CONFIG and is controlled by whether or not the caller has selected to be in color graphics mode or not. There are two extremes on the use of color: use none or use it everywhere. By using no colorization, RBBS-PC's performance is optimized. RBBS-PC does not have to go through the overhead of transmitting special instructions to control the caller's screen. The two chief functions of BBSs, transmission of textual information and file exchange, do not essentially involve the use of color. Of course, there are those who want their RBBS-PC's visual displays to convey as much as the text or the files themselves (i.e. the message is in the medium). These are the SysOps would elect to use color everywhere. With the use of color, plain text begins to look drab and uninteresting and attention tends to focus on the colorized text. For this reason, some SysOps find it difficult to use color in some places and not in others. Colorization is implemented in RBBS-PC with ANSI display commands. In order for a caller to see the colors as RBBS-PC displays them, the terminal emulator used by the caller MUST be ANSI-compliant. CONFIG allows the SysOp to activate and customize colorization on screen 17, "RBBS-PC Color Parameters". 1) Use CONFIG's parameter 321 to put in a string for turning EMPHASIS on. The recommendation is a bright foreground on red background ("[27][1;41m"). 2) Use CONFIG's parameter 322 to set the string for normal text. This is the general default color and is used to turn off emphasis. The recommended color is amber (normal yellow) ("[27][0;33m"). 3) Use parameter 323, 324, 325 and 326 of CONFIG to set the four caller foreground colors. CONFIG uses natural language phrases to set these, so it is very easy. The recommendation, in order, is: bright green, bright yellow, bright purple, and bright cyan. These colors are all used in the message header and general command prompt. Foreground 4 is used to highlight the commands the caller actually needs to type in to select that option. No colors will be displayed if these parameters are set to empty strings. Callers can turn off the colorization simply by going into Utilities and T)oggle H)ighlite to "off". The default in RBBS-PC is for colorization to be OFF. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-26 Colorization is based on the ANSI standard. Special codes are sent by RBBS-PC to the callers system, which must then be interpreted by the caller's communications software. 7.11 RBBS-PC's Automatic Operator Page Option --------------------------------------------- RBBS-PC will "automatically page" the SysOp whenever a specified caller or group of callers logs on to RBBS-PC or joins a specific "sub-board". The selection criteria can be a specific caller's name, a range of security levels, or whether the caller is a new user. A SysOp may wish to be notified for any number of reasons including: - A caller has been causing trouble on the bulletin board and needs to be monitored. - The SysOp wants, for security reasons, to be notified when anybody logs on with a SysOp security level. - The SysOp wants to chat with a friend but does not want to continually monitor RBBS-PC's activity. AutoPage is controlled by a file whose name is specified in CONFIG parameter 18 (the default name is AUTOPAGE.DEF). Each line in the file is a separate AutoPage command. The line contains 4 parameters separated by commas. The format is <condition>,<notify caller?>,<# of times>,<music> <condition> Can be a NAME enclosed in quotes, the string "NEWUSER", or a security level range specified in the format /<min sec>/<max sec> where: <min sec> is the minimum security level <max sec> is the maximum security level <notify caller?> Is "N" if the caller also is to be notified that the SysOp has been notified when the caller logs on. Anything else means the caller will not know that the SysOp has been paged automatically. <# of times> Is the number of times that the PC's speaker will be sounded. <music> Is a BASIC music command to be used instead of a beep. If nothing is specified, a beep will be used. Warning: on some PC's the playing of music produces "out of string space errors". Test any music before using. Beeps always work fine. Examples: "SEXY DEVIL",,1,L4EDC AutoPage when a caller named SEXY DEVIL logs on, do not notify the caller, and play "L4EDC". "GREGG SNYDER",N,2, AutoPage when GREGG SNYDER logs on, notify the caller, and beep the speaker twice. PLANNING YOUR USER INTERFACE 7-27 "NEWUSER",,1, AutoPage when any new caller logs on, do not notify the caller, and beep the speaker once. /10/12,N,2, AutoPage when anyone with security 10 through 12, inclusive, logs on, let them know that the SysOp wants to be notified that they are on, and to beep the Speaker twice. The status line at the bottom of the RBBS-PC screen will read "AP!" for the duration of the caller's session if RBBS-PC has automatically paged the SysOp. This allows the SysOp to know that the AutoPage took place, even if the SysOp was not present at the beginning of the call. If the caller triggers more than one AutoPage command, the first condition encountered will be used. Since each "sub-board" can have a different AutoPage command file, the SysOp has the option to be automatically paged based on different criteria for each "sub-board". 7.12 Enhancing the File View Function ------------------------------------- Within the File Subsystem of RBBS-PC the V)iew function, allows the caller to get a list of files that are "archived" inside a single file. RBBS-PC supports .ARC, .LZH, .PAK, and .ZIP compression formats, as well as ANY format using SysOp-installed external procedures. RBBS-PC assumes that the file extension will identify the type of compression. Hence, the SysOp can install a View function for files with extension ".XYZ". All the SysOp must do is put a .BAT file with the name "Vxyz.BAT" on the same disk and path specified for COMMAND.COM via CONFIG parameter 105. If such a file is present, RBBS-PC will shell to the command in Vxyz.BAT whenever a caller asks to V)iew any file with the extension .XYZ. SHELLing requires extra system RAM beyond what RBBS-PC uses. If your system has little or no free memory, you may be limited to using the internal V)iew feature of RBBS-PC. RBBS-PC includes the following files for external View support: ARCVIEW.COM Compiled C program for view of DWC, PAK, ZOO, and ARC files. Used in VDWC.BAT, VZOO.BAT. VDWC.BAT Processor for DWC files VZOO.BAT Processor for ZOO files Each BAT file contains in it: ARCVIEW [1] > [2] RBBS-PC will SHELL to the above program (not to the BAT file) after first substituting the name of the file to be listed for "[1]" and the name of the file to place the results of the listing for "[2]". The ">" is the DOS "redirect" function, which causes the output to be placed in the file instead of on the local screen. The file specified in [2] is named "NODE?WRK" when the wildcard "?" is the node id (1,2,3,...). RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-28 How to Implement Your Own View function --------------------------------------- Your view program must have a way to receive from RBBS - the name of the file to list - the name of the file to write the listing to. RBBS-PC will interface with your program in two different ways, depending on how many lines your BAT file contains. If the BAT file contains exactly 1 line, RBBS-PC will shell to the line in the BAT file and not to the BAT file itself. RBBS-PC will dynamically scan for "[1]" and "[2]" in the line and substitute the names of the file to be listed and the file to write the results to, respectively. Everything else will be left intact. If the BAT file contains more than one line, RBBS-PC will shell to the BAT file, passing as command line parameters the name of the file to list, and the name of the results file. For example, the following BAT file could be used: ECHO OFF ECHO %1 >> VIEW.LOG ARCVIEW %1 > %2 ECHO ON The statement "ECHO %1 >> VIEW.LOG" will create a list of all files selected for view. ">>" means to append the view file name to a file called "VIEW.LOG". Using ZIPTV ----------- Ziptv is a program distributed by Samuel H. Smith which supports not only View, but the ability to list any file inside of a ZIP file, thus allowing users to view documentation before downloading a file. Many SysOps will want to install ZIPTV to replace the internal RBBS-PC View function. To do so, create a VZIP.BAT as follows: DEL %2 <path>ZIPTV -P%3 %1 Where <path> is the drive and subdirectory where you have placed ZIPTV.EXE. 7.13 Bulletins and News ----------------------- RBBS-PC has very powerful and flexible features for broadcasting system- wide information to callers. The following table describes the various NEWS options: PLANNING YOUR USER INTERFACE 7-29 ┌───────────────────────────┬─────────────────────────────────────────────┐ │ When the caller will see │ Which file will the caller see │ │ the news │ │ ├───────────────────────────┼─────────────────────────────────────────────┤ │Every time the caller logs │The file PRELOG is displayed before callers │ │on. │are asked their names. This information │ │ │should be kept very brief. │ ├───────────────────────────┼─────────────────────────────────────────────┤ │Only when a NEW USER logs │The file NEWUSER is shown to new users only │ │on. │the first time they log on. │ ├───────────────────────────┼─────────────────────────────────────────────┤ │On every call, after the │The file WELCOME is displayed after a │ │caller logs on. │successful logon. For graphic and color │ │ │versions of this file, see section 6.3. │ ├───────────────────────────┼─────────────────────────────────────────────┤ │Only when the SysOp has │The NEWS file is displayed if the date of │ │updated information since │last log on is the same or earlier than the │ │the last time the caller │date of the news file. The news file also │ │was on the BBS. │can be read by using the "B N" command │ │ │(Bulletin News). │ ├───────────────────────────┼─────────────────────────────────────────────┤ │Every time the caller logs │The logoff questionnaire, EPILOG.DEF is │ │off. │processed at logoff, and can be used to │ │ │display news at this time. See section 19. │ ├───────────────────────────┼─────────────────────────────────────────────┤ │Available on request by │The RBBS-PC general Bulletin files. │ │the caller. │ │ └───────────────────────────┴─────────────────────────────────────────────┘ General Bulletin Files ---------------------- General bulletins are text files prepared by the SysOp that can be viewed by the callers when they first log on, or at any time during the caller's session. To configure bulletins, you must first decide if you will used NUMBERED bulletins, NAMED bulletins, or both. The only difference between numbered and named bulletins is in how RBBS-PC scans for new bulletins when a caller logs on. With numbered bulletins ONLY, RBBS-PC uses the number of bulletins specified in CONFIG parameter 62 to find new bulletins. If the SysOp uses NAMED bulletins, each bulletin must be identified to RBBS-PC (in the file BULLET.FCK) in order to scan for new bulletins. To create a bulletin, use CONFIG parameter 61 to set the location and name of the bulletin menu, and set parameter 63 to the desired bulletin prefix. If you are using numbered bulletins, also set parameter 62 to the number of bulletins. Ex: Set parameter 61 to: C:\RBBS\BULLETIN\BMAIN.MNU Set parameter 63 to: B When RBBS-PC looks for bulletins, it will use parameter 61 for the location of each bulletin, and parameter 63 to build the file name. If you would like a bulletin named TEST, RBBS-PC will look for the file C:\RBBS\BULLETIN\BTEST. Any TEXT editor can be used to create bulletins. The bulletin can contain ASCII text, extended ASCII graphics, or ANSI color. By naming the bulletins properly, RBBS-PC's graphic support will display the proper bulletin to the caller (e.g. BTESTC. would be the COLOR version of bulletin TEST). See section 6.3 for details. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-30 The bulletin menu defined in CONFIG parameter 61 should contain a list of available bulletins. The .MNU extension activates RBBS-PC's sub-menu feature (see section 7.7). If only numbered bulletins are used, RBBS-PC will be able to scan for new bulletins automatically (as long as parameter 62 has the proper setting). For named bulletins, you must create a list of bulletins for RBBS-PC to scan. The list should be in the file <prefix>.FCK in the same directory as all the bulletins. The <prefix> is what is specified in parameter 63. In our example, this file would be called B.FCK. Each bulletin should be listed, without the prefix, one per line. Ex: TEST 1 2 RBBS-PC would check the date of the files BTEST, B1, B2 and BRBBS-PC. Note that B1 and B2 are considered Numbered bulletins, but if B.FCK is used, ALL bulletins are considered Named bulletins. News Bulletin File ------------------ The NEWS file is a special bulletin that is automatically displayed to a caller at login if it has been updated since his last call. The NEWS bulletin is NOT located with the general bulletin files. It should be placed in the same directory as the WELCOME file. The name of the NEWS file is <conference>.NWS. The <conference> is the name of the RBBS-PC conference to which the news belongs (each conference can have a separate news file). The MAIN news file, shown to callers at login, is named MAIN.NWS. News files can support color and graphics (see section 6.3). UNIQUELY IDENTIFYING YOUR CALLERS 8-1 8. UNIQUELY IDENTIFYING YOUR CALLERS ------------------------------------ All callers need a way to identify themselves to RBBS-PC and to other callers. RBBS-PC expects each caller to set a password so that other callers cannot easily pretend to be that caller. Callers are most easily known on bulletin boards the same way they are known in real life - by first and last name. This is why the default configuration in RBBS-PC uses first and last name to IDENTIFY users. The first/last name is the caller's identity or ID. RBBS-PC also allows the SysOp to identify callers uniquely by something other than their first and last names. Perhaps the SysOp wants a one word alias to be allowed, or perhaps callers must use a preassigned access code (access code, employee number, account number, etc.). RBBS-PC allows ANY FIELD inside the users file to be used for identification. Since there are empty, unused areas in the user file, a SysOp can even create a new field to be used for caller identification. When anything other than name is used to identify users, RBBS-PC still wants callers to specify their names. It just does not use that information to identify them. A fairly common problem on bulletin board systems with large user lists is that two callers can have the same first and last name. A caller discovers this when they are unexpectedly asked for a password on the first call to a new system, indicating that another caller has already used that name. Further, since RBBS-PC is used world-wide many non-English speaking countries have callers with names that have embedded blanks, etc. RBBS-PC alleviates this problem by allowing interior blanks in first and last names. Thus JIM JONES can register as JIM K JONES or JIM JONES SR or JIM JONES III. By allowing ANY field inside the user record to be used to uniquely identify individual callers, RBBS-PC alleviates the basic problem of having two callers with the same name. This additional INDIVIDUATION field is used to distinguish callers with the same ID. When individuation is used, callers will have to specify both the identifying and individuation field. Both are used to find a record in the users file. This individuation field can likewise be a new field created by the SysOp. For example, the SysOp can specify that callers be uniquely identified by both their name and their CITY/STATE. Alternatively the SysOp can specify that callers are to be uniquely identified by their telephone number, which would be a new field for RBBS-PC to store. Note that when using individuation, ALL callers must use it, not just the ones with identical names. 8.1 Setting Up Identifying and Individuation Fields --------------------------------------------------- The identifying and individuation fields in RBBS-PC are controlled by parameter 41 through 46 in CONFIG. The default is to use the caller's first and last name to uniquely identify a user. The fields available to uniquely identify a caller (other than the caller's first and last name) are designated in CONFIG by the starting position in the users file and length. It is essential therefore to understand WHERE FIELDS ARE STORED IN THE USER FILE. Consult Appendix A for a detailed layout of the user file. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 8-2 RBBS-PC's flexibility requires care when selecting the locations of fields used to identify and individuate, because options can be selected that make no sense. For example, it is possible to specify the user preference field, which means that every time a user changed preferences, such as default protocol, the user would have a different ID. There are only two fields in the user file that make sense for identifying users: 1) first/last name (column positions 1-31), or 2) a field designated by you as the SysOp for your RBBS-PC. For a SysOp-designated field, only 4 choices make sense: a) none, b) name (columns 1-31), c) city/state (columns 63-86), or d) positions 87-97 in the user record currently "unused." Positions 87-97 of the users record (currently unused) provides a potential 11 columns to use for SysOp designated fields. However, there is no guarantee that these positions will not be used in future releases of RBBS-PC. Additional fields will be used from the far right. Any SysOp intending to utilize this area of the users record is safest if the field selected begins in column 87 and is as short as possible. When a SysOp-designated field is created, the SysOp must also supply the prompt to be used with the field. The prompt is what is displayed to the caller when asking for the value of the field. RBBS-PC uses the callers first and last name for the "to" and "from" fields for messages even when the users name is not the field used to uniquely identify callers. 8.2 Preloading Identities For Instant Access -------------------------------------------- SysOps who operate bulletin boards that are open to new callers have no problems giving a new caller instant access -- new callers register, set their identity and password, and are recorded in the USER file. SysOps that operate bulletin boards that are only available by subscription or who delay access operate differently -- a user must already know and be able to state identity, individuation, and password in order to get on. To add a new user, the values of these fields must be communicated back to the caller in order for them to have access. To overcome this cumbersome approach, some SysOps allow new callers on their system (at a reduced security level) and then raise the security level of the caller once the caller has met whatever criteria the SysOp has set for access to the system. Typically new callers must call back and continue to check to see if their security level has been raised. Systems that do not let new callers on require the SysOp to enter the appropriate information for each new user, contact the new caller by mail or phone, and let them know how to connect to the RBBS-PC. Both approaches introduce delays to new callers for getting on and additional time, expense and overhead for the SysOp. RBBS-PC provides a systematic solution to the problem of delayed access for new user. A SysOp can add a user WITH NO VALUE FOR THE INDIVIDUATION FIELD OR PASSWORD. These fields can be left blank. When a caller logs on with a proper ID and RBBS-PC finds an individuation value or password that is UNIQUELY IDENTIFYING YOUR CALLERS 8-3 blank, it lets the caller set the value of those fields without requiring a match. Subsequent calls, but not the first, must match the value set for individuation and password. Even though a SysOp can add a user and leave the password and individuation blank, this still requires that the SysOp add the user only after an ID is agreed to by both parties. What if this access is still not fast enough? The solution provided by RBBS-PC is for the SysOp to "pre-load" IDs and give out a pre-loaded ID to the caller for instant access, so that the client does not have to wait even for the SysOp to add the ID. Since there is no way to set in advance how a user wants to be identified, the SysOp can set up essentially random account IDs which are difficult to guess. Callers who pre-pay the subscription fees can be given a valid pre-loaded ID for instant access. The ability of RBBS-PC to use any field for an ID, and let the first call set individuation and password, means that RBBS-PC can support boards where instant access is a critical part of their service. RBBS-PC's AUTOMATIC SUBSCRIPTION/TIME MANAGEMENT 9-1 9. RBBS-PC's AUTOMATIC SUBSCRIPTION/TIME MANAGEMENT --------------------------------------------------- RBBS-PC has support built into it for managing access based on the date of the call, and the time of day. As with the other RBBS-PC features, this support is optional. The primary uses of this facility are: - to make it very easy to control access based on subscription dates. - to give callers a temporary, date-limited boost in privileges. - to vary the amount of time that a caller has for a session based on the time of day. Once subscription management is configured, RBBS-PC handles all subscription maintenance. After a user is registered, RBBS-PC will automatically: 1) warn users before their subscription expires 2) reduce the security of callers whose subscription has expired. The SysOp can send a message when the subscription is about to expire, by creating the file RGXPIRE.HLP and placing it in the RBBS-PC help file directory. The number of days before expiration to warn is set with CONFIG parameter 50. When a caller's subscription expires, their security will be updated, and the help file RGXPIRD.HLP (if it exists) will be displayed. The subscription and time management system can also be used to grant callers a temporary boost in privileges. For example, giving new callers a "free" trial period. Just as cable TV channels sometimes have a free week of viewing to attract new subscribers, a SysOp of a subscription RBBS-PC can set up limited free offers. By setting up a default subscription period of say, 5 days, all new callers can be let onto to see whether they want to subscribe. After 5 days, security drops back down to a more limited level. This "free" period can be made a standing offer, or turned off after a two week period. Or, a user who requests a trial period can be individually added with a short subscription period. Limited trial subscriptions also are an attractive alternative for those SysOps that do not give full privileges until after a caller is verified. These callers are either asked to fill out a registration form or leave a comment, and the SysOp later decides whether to increase the security level. By letting new users have a short registration period with higher privileges, say 3 days, a SysOp may choose to give new callers immediate access, so the caller is not penalized while waiting for the SysOp's decision. The SysOp need do nothing if a caller cannot be verified, as RBBS-PC will automatically reduce their security in a few days. The SysOp will manually raise the security of callers who are verified. 9.1 Setting It Up ----------------- The subscription management system is turned on by specifying in CONFIG to limit callers by subscription date. After access is so limited, RBBS-PC automatically records the date of the first call. For old users, this will be the first call made since RBBS-PC began to limit access. This recorded date is the base registration date. The SysOp then needs to specify in CONFIG: - A default subscription period (the number of days a new user gets). RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 9-2 - A warning period (which determines when callers will get an advance warning that their subscription is about to expire. The warning period is the number of days left before triggering a warning.) - The security level expired subscribers get. In the PASSWRDS file, the SysOp designates different subscription periods for each security level (other than the default security level). This needs to be specified only if a subscription period is desired that will override the default. RBBS-PC determines when the subscription will expire by adding the subscription period to the base registration date. Persons calling after this expiration date are reduced to the expired security level set by the SysOp in CONFIG. The time management of RBBS-PC is automatically activated when the presence of the PASSWRDS file is detected. See section 15.3 for a complete description of the PASSWRDS file. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-1 10. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC --------------------------------------------------- The CONFIG program creates and edits the RBBS?PC.DEF files. These files contain configuration information for each node of RBBS-PC. CONFIG also edits the "sub-board" configuration files. Lastly, CONFIG contains functions for periodic maintenance, such as create and pack MESSAGE and USER files, renumber messages, and modem firmware initialization. A sample RBBS-PC.DEF file is supplied with RBBS-PC. New SysOps are urged to use this sample, as it will avoid many of the "first-time" setup errors. Once you are comfortable with your RBBS-PC, CONFIG will allow you to shape your BBS as you desire. CONFIG is divided into many screens. They are: Screen Description 1 Global RBBS-PC Parameters (Part 1 of 3) 2 Global RBBS-PC Parameters (Part 2 of 3) 3 Global RBBS-PC Parameters (Part 3 of 3) 4 RBBS-PC System Files (part 1) 5 RBBS-PC System Files (part 2) 6 Parameters for RBBS-PC "doors" 7 Parameters for RBBS-PC Security (part 1) 8 Parameters for RBBS-PC Security (part 2) 9 Parameters for Multiple RBBS-PC's and "conferences" 10 RBBS-PC Utilities 11 Parameters for RBBS-PC's File Management System 12 RBBS-PC Communications Parameters (part 1) 13 RBBS-PC Communications Parameters (part 2) 14 RBBS-PC Net Mail 15 New users parameters 16 Use of the Library Sub-System 17 RBBS-PC Color parameters 18 Reserved for future use You may scroll forward or backward through the screens by using the PgUp and PgDn keys on the keyboard. Additionally, you may go directly to a specific screen by pressing a function key (F1 through F10) or SHIFT and a function key (shift/F1 through Shift F7) corresponding to the page to be selected. To terminate CONFIG, press the "End" key on the keyboard. CONFIG can be invoked with the command: CONFIG <config file> The <config file> is an optional name of the configuration file to be created or edited. If no config file is specified, CONFIG will edit the file RBBS-PC.DEF in the current subdirectory. Each CONFIG parameter, and the default values are explained in the following sections. 10.1 Global RBBS-PC Parameters (Part 1 of 3) -------------------------------------------- Parameters 1 and 2 TOM MACK The RBBS-PC system operator's (SysOp) first and last name. Enter your REAL name here (the name you wish your callers to know you by). NO ONE may log in to your RBBS-PC using this name, NOT EVEN THE SYSOP! This is a security feature of RBBS-PC. The SysOp logs on with a "pseudonym" (see parameter 121). RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-2 Parameter 3 EXPERT The mode (EXPERT of NOVICE) for the SysOp. This option is now obsolete. The SysOp may use the RBBS-PC eXpert command. Parameter 4 0800 to 2200 The SysOp's "office hours", or when a user can page the SysOp. If a caller attempts to page you outside these hours, he will be told you are not available, and RBBS-PC will suggest that he try a MSG or a COMMENT. The times are set using a 24-hour military clock (i.e. 10:00 P.M. is 2200 hours). The SysOp can disable a caller's ability to page him COMPLETELY by pressing the function key F4 while RBBS-PC is running. F4 toggles the SysOp page status off and on. Parameter 5 NO Because the bell on an attached printer is often louder than the one built into the PC, the SysOp can elect to have the printer's bell used, rather than "beeping" the PC's speaker. Parameter 6 YES Should RBBS-PC automatically take itself off-line if a "disk full" condition occurs. In some instances, such as having a small disk volume for uploads, you may want your RBBS-PC system to remain online, even though it is getting disk space full errors. Parameter 7 OFF The default setting for the "prompt bell". The prompt bell refers to a preference some callers have of getting a short "beep" from the system, whenever it pauses for input at a prompt. When this is on, both the remote user and the local SysOp will hear the prompt bell when input is required from the remote user, unless and until this option is changed with the Toggle command on the Utility menu. Parameter 8 72 MINUTES The maximum amount of time (in minutes) each user is to be allowed on the system per session (the "session" refers to any individual call to the bulletin board). This is the default time limit, which only takes effect if the PASSWRDS file does not override. See section 15.3). Parameter 9 0 MINUTES The default total amount of time (in minutes) a caller is allowed on RBBS-PC per day. This is the default time limit, which only takes effect if the PASSWRDS file does not override. See section 15.3). Parameter 10 1 This allows a SysOp to "reward" users who upload files by adding time to the users session when they upload. This number will be multiplied by the time spent in upload, and credited to the user. Setting this parameter to 1 will give back the user as much time as they spent uploading, so their session time will look "frozen" during upload. These time credits are normally removed at the end of a day, unless the ratio you set is greater than 1. If so, CONFIG will ask if you want to make the time credits "survive." If so, the extra time granted the user will be available indefinitely, instead of only for the current day. Parameter 11 1 The number of months inactivity that must elapse before a user is considered a candidate for deletion from the USERS file when the SysOp "rebuilds" it. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-3 Parameter 12 RBBS-PC Allows the SysOp to specify the name of the RBBS-PC that is to be displayed when a user first connects with the system and prior to completing the logon process. Parameter 13-15 FG=7, BG=0, BORDER=0 Allow the SysOp to specify the colors desired for the console display. Foreground, Background, and Border may be set. When specifying colors, use the following: 0 = Black 4 = Red 1 = Blue 5 = Magenta 2 = Green 6 = Brown 3 = Cyan 7 = White Add 8 to any number to set high intensity. Add 16 to turn blink on. Parameter 16 NO If the RBBS-PC computer can support ANSI, RBBS-PC will send ANSI control sequences to display color and position the cursor. The local display does NOT have to support ANSI in order for callers to receive ANSI commands, although it does make the "snoop" function readable. Parameter 17 123 The decimal value (0 to 255) of the character used to identify "SmartText" codes. This should ALWAYS be set to 123. See section 7.9 for a detailed discussion of SmartText. Parameter 18 AUTOPAGE.DEF The file name that contains the information to control the "automatic" RBBS-PC paging of the SysOp. See section 7.11 for a detailed description of the AutoPage feature. Parameter 19 OLD & NEW The level of detail to use when notifying callers of electronic message. This can be set to (A)ll (old and new mail notifications), (N)ew mail only, or (S)kip (no notification). See section 18 to get a better understanding of the full flexibility of mail waiting notification that has been built into RBBS-PC. 10.2 Global RBBS-PC Parameters (Part 2 of 3) -------------------------------------------- Parameter 21 YES Instructs RBBS-PC to remind users not only of the messages that are for them, but also messages that they have left. This is to encourage users to delete their old mail and help to keep the MESSAGES file to a minimum. Parameter 22 NO Instructs RBBS-PC to remind users, when they login, how many files they have downloaded and uploaded. Parameter 23 NO Reminds users every time they log on of the preferences they have selected for such things as file transfer protocol, graphics, nulls, etc. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-4 Parameter 24 NO Allows users to download files immediately upon logging on to RBBS-PC. Parameter 24 is only meaningful if the RBBS-PC File Management System (FMS) has been enabled via parameter 214. RBBS-PC will scan FMS for the newest uploads. When a caller logs on, RBBS-PC will determine how many files are new since the caller last logged on. If parameter 24 is YES, the caller is offered the chance to immediately review these new files and download them, if the caller has sufficient security to download. This happens before the bulletins or messages are reviewed. RBBS-PC's that emphasize software exchange may want to enable this option, others may not want to give the caller a chance to download the new files until after bulletins and messages have been reviewed. Parameter 25 23 Allows the SysOp to establish a default page length for users when they log on. The valid range is 0 to 255. If set to 0, the user will receive continuously scrolling output. Parameter 26 19 The maximum number (from 1 to 99) of lines allowed in each message. Parameter 27 YES Allows the SysOp to make the system "welcome" file interruptible. The default is that YES it is interruptible. However, if the SysOp feels too many people are bypassing it and it contains essential information, the SysOp can set this parameter to NO (i.e. the user can not suspend or cancel the listing of this file at their terminal with a CTRL-S or CTRL-K). If the welcome file has intricate graphics, interrupting it may leave the caller's screen in an odd color. Parameter 28 YES Allows the SysOp to indicate if the system bulletins are optional for users when they log on. If bulletins are optional, callers can elect to automatically bypass old bulletins and be notified only when there are new bulletins. RBBS-PC will check the file date of the bulletins and inform the caller which are new, with the option to read all of the new bulletins. If none are new when bulletins are optional, the bulletins will be automatically bypassed. See section 7.13. Parameter 29 IBM PC Tells RBBS-PC how to handle non-standard systems. The Compaq/Plus uses interrupt X'7F', which is also used by MultiLink. RBBS-PC may incorrectly detect MultiLink on a Compaq/Plus or other system that makes use of interrupt X'7F', unless you select computer type 1. The IBM PCjr's non-standard comm port mapping can be overcome if you select computer type 2. Type 0 (IBM) and 3 (other) are treated the same. Parameter 30 - 34 (see CONFIG for defaults) The symbol used to activate each online command can be changed. This allows you great flexibility in how RBBS-PC interprets commands. You can substitute any keyboard character for each command. To disable a command, enter a single space for the symbol. One reason to change commands is for macros. If you want to write an RBBS-PC macro that acts as a "front end" for the command, you should first change the symbol of the command to an unused, "hidden" symbol. Next, create the macro, naming it the same as the original key. In the macro, you can activate the original function by using the new "hidden" symbol. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-5 Parameter 35 YES Allows the section name to precede the command prompt. The section is MAIN, FILE, LIBRARY, or UTIL, if this option is selected. Otherwise, the prompt will begin with YOUR. Normally the section in the prompt helps the caller remember where he is, but see section 7.5 for reasons to suppress the section. Parameter 36 YES Suppresses the display of commands in the command prompt. By default, RBBS-PC reminds the caller what commands are available by giving a sorted list of the letters used for each command in the command prompt. RBBS-PC shows only the commands available in the section that the caller is in. Parameter 37 NO RBBS-PC will either restrict commands to those in the current section, or will look in ALL sections for a valid command that matches the caller's request. See section 7.4. Parameter 38 YES Instructs RBBS-PC to use machine language subroutines (rather than the BASIC routines) for selected functions. RBBS-PC includes both BASIC and machine language versions of several functions. The machine language version is much faster, but may cause problems with some non- standard systems. Normally, you should activate the machine language version, but if you encounter erratic behavior, especially in locating files on a machine that may not be 100% IBM compatible, try using the BASIC subroutines. Parameter 39 NO Instructs RBBS-PC to use the BASIC language's PRINT statement to write to the screen of the PC that RBBS-PC is being run on. This is sometimes necessary in "hostile" environments (i.e. multitasking, special screen drivers, etc.) where the use of RBBS-PC's default call to the RBBS-PC screen driver ANSI is not viable. Parameter 40 2 The maximum number of additional lines that a caller can use to describe a file that was uploaded. It applies to both single FMS directories and non-FMS directories. NOTE: This number counts the EXTENDED description lines. RBBS-PC always allows a single-line description. 10.3 Global RBBS-PC Parameters (Part 3 of 3) -------------------------------------------- Parameter 41 (NAME) Determines how callers are to be identified when they log in. By default, RBBS-PC uses the NAME field in the USER file. You may specify the starting offset of the field, and its size. WARNING: misuse of this parameter could DESTROY your USER file! Parameter 42 <none> Allows an additional field to be used to distinguish callers with the same ID (see section 8). Normally, this item is set to 0, which instructs RBBS-PC to not allow callers with identical IDs. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-6 Parameter 43 1 The offset into the USER record to be used to identify a user for PERSONAL downloads. By default, RBBS-PC uses position 1, which is the start of the caller's name. Parameter 44 31 The length of the field used to identify a user for PERSONAL downloads. By default, RBBS-PC uses 31 (the maximum length of a user's name). The entries in the personal download directory must have exactly this many bytes at the end -- plus one (for the flag used to indicate if the file has been download). Parameter 45 FIRST name The prompt that RBBS-PC should use when asking the caller for the first ID field. When prompting for this input, RBBS-PC will prepend "What is your" to the prompt. Parameter 46 LAST name The prompt that should be used for the second ID field. Parameter 47 NO Activates upload/download ratios. See section 15.3 for a discussion of the flexibility of RBBS-PC ratios. NOTE: If you elect to enforce ratios, fields in the USER record are used to store ratio information. See Appendix A for details. Parameter 48 NO Activates automatic security level reduction via Subscription date. See section 9 for a complete explanation of subscriptions. Parameter 49 5 The security level to which callers will be set when their subscription expires (see section 9). Parameter 50 60 The number of days BEFORE a caller's subscription is to expire that RBBS-PC will send warnings. The file RGXPIRE.HLP can be customized to inform the caller that the subscription is about to expire, and what to do. Parameter 51 365 The default number of days in a subscription period. When a caller logs in this many days after their subscription began, RBBS-PC will notify them of the expiration, display the file RGXPIRD.HLP, and reduce their security to the level specified in parameter 49. Parameter 52 NO Instructs RBBS-PC to turn off printer logging each time RBBS-PC "recycles" at the end of a call. Since printer errors will often "hang" a system (especially if no printer is present), this function can avoid errors caused by the SysOp accidentally activating RBBS-PC's printer log function. Of course, if you wish to use the printer logging feature, you must set this parameter to NO. Parameter 53 NO Instructs RBBS-PC to play musical themes for auditory feedback on what is happening on the BBS. This can be important for SysOps that are sight impaired. These musical themes are "played" on the speaker of the PC that is running RBBS-PC, but not transmitted to the caller. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-7 Song played Meaning to SysOp --------------------------------------------------------- "Consider Yourself" User log-on "Walk Right In" New User log-on "Dragnet Theme" Security violation "Goodbye, Charlie" User log-off "Taps" Caller denied access "Oom Pah Pah" User downloading file "Thanks for the Memories" User uploading file Parameter 54 128 The buffer size used internally by RBBS-PC when displaying text files such as menus, directories of files, etc. The size can range from 32 to 4096 characters. The bigger the buffer, the fewer disk accesses necessary to display the file and the faster the display will be. The default of 128 is the minimum recommended. Increasing this to 512 will increase the speed of text displays. However in some environments where it is important to respond quickly to XON/XOFF control, this should be set to the minimum of 32. Parameter 55 1024 Sets the size of RBBS-PC's internal "stack." The internal stack is used by RBBS-PC to keep track of program flow. The recommended value is 2048. If you must conserve RAM usage, this number can be decreased, but program errors such as "Stack overflow" and "String Space Corrupt" could result. Parameter 56 is not implemented in RBBS-PC. Parameter 57 CITY and STATE Specifies the prompt RBBS-PC should use when requesting the caller's city & state. If you would like to record information other than city & state in this USER field (telephone number, for example), change this prompt accordingly. Parameter 58 NO Specifies how directories are sorted when a caller requests a list of ALL download directories. You can either specify no sort, or the directories can be shown in the order they appear in the "directory of directories." Parameter 59 1024 Specifies the buffer sized used during INTERNAL protocol transfers. This is the amount of data stored before it is written to disk on upload, or the amount read from disk at a time on download. The range is 128 to 8192 characters (1024 is recommended). Parameter 60 <none> Specifies that either a Computalker (B.G. MICRO, P.O. Box 280298, Dallas, Texas 75228) or HEARSAY 1000 (HEARSAY Inc., 1825 74th Street, Brooklyn, N.Y. 11204) speech board is being used. This is in support of the sight impaired SysOps. These voice synthesizers can speak status messages that are usually either written to the CALLER log or printed to the printer. With this, a sight-impaired SysOp can hear what the caller on the BBS is doing. To support as many speech boards as possible in the future, RBBS-PC uses a 64 entry file (RBBSTALK.DEF) to contain SysOp-definable fields. The file is accessed randomly with fixed-length 32 byte records. The last two bytes RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-8 must contain CR/LF leaving 30 bytes available for the text. The 64 records are predefined and used by RBBS-PC as follows: 1 = LOGON USER MESSAGE 2 = MAIN MENU PROMPT 3 = FILES MENU PROMPT 4 = UTILITY MENU PROMPT 5 = DOOR MENU PROMPT 6 = LIBRARY MENU PROMPT 7 = LOGOFF MESSAGE 8 = DOWNLOAD PROMPT 9 = UPLOAD PROMPT 10 = TIME REMAINING PROMPT 11 = WELCOME BACK PROMPT 12 = CONFERENCE MENU PROMPT 13-64 available for future enhancements SmartText IS supported in the RBBSTALK.DEF records. The CompuTalker requires the use of COM2, so the modem used by RBBS-PC must NOT be connected to COM2. 10.4 Parameters for RBBS-PC System Files (part 1) ------------------------------------------------- Parameter 61 \BULLET The path and name of the text file that describes the BULLETINS. RBBS-PC uses the path of this file to find ALL bulletin files. Parameter 62 6 Instructs RBBS-PC to use "numbered" bulletins, and tells RBBS-PC how many numbered bulletins to look for (see section 7.13). Parameter 63 BULLET Specifies the PREFIX of the Bulletin files. Ex: If the prefix is "B", and a user asks to see bulletin INFO, RBBS-PC will look for the file "BINFO" in the same directory as the file specified in parameter 61. Additionally, if the file "BINFO.MNU" is found, RBBS-PC will activate the Sub-Menu feature (see section 7.7). If the user has specified graphics or color display, the files, RBBS-PC will also search for the files "BINFOG" and "BINFOC" (see section 6.3). Parameter 64 (default drive) Specifies the disk drive and path on which RBBS-PC will find on-line "help" files. Parameter 65 HELP0 Specifies the prefix for the last remaining "old-style" help files. These files are supplied with RBBS-PC, and the prefix is "HELP." There is no reason to change this parameter. Parameter 66 HLP Specifies the EXTENSION for the "new-style" help files. A full set of online help is provided with RBBS-PC. There is no reason to change this parameter, but if you do, all .HLP files must be renamed. Any additional help files you wish to create should have this extension, and be in the directory specified in parameter 64. If so, RBBS-PC will treat your help files as if they were part of RBBS-PC, displaying them to callers when they are requested. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-9 Parameter 67 UPCAT The help file shown to callers when RBBS-PC asks them to categorize an upload. With FMS directories (see section 12), a caller can specify the category code for their upload. You need only specify the base file name in this parameter. RBBS-PC will add the help file PATH (as specified in parameter 64) and the EXTENSION (as specified in parameter 66). This file should contain a description of each category, so the uploade can properly categorize the upload. Parameter 68 NEWUSER The path and filename of the file new users see when they first log on and before they "register" themselves in RBBS-PC's USERS file. A user sees it once and only once during his first session. Parameter 69 WELCOME The path and filename of the file each user sees EVERY time AFTER they log on. Parameter 70 MENU1 The path and filename of the SysOp command menu, shown to callers in NOVICE mode who have access to SysOp commands. Parameter 71 MENU2 The path and filename of the MAIN section menu. Parameter 72 MENU3 The path and filename of the FILE section menu. Parameter 73 MENU4 The path and filename of the UTIL section menu. Parameter 74 CONFENCE The path and filename of the Conference description file. RBBS-PC uses this file to when a caller asks for a list of your conferences, and also uses the file to validate a JOIN command. In order for the JOIN to work, the conference name (seven characters or less) must appear IN CAPS, at the beginning of a line (preceding spaces are allowed). The SysOp must already have pre-formatted the messages and users files associated with the conferences (see section 17.3). RBBS-PC will look for conference MESSAGE files in the path specified in this parameter after searching where the main MESSAGE file is located. Parameter 75 MENUA The path and filename containing the list of the questionnaires callers can answer on-line (see section 19). Before RBBS-PC will allow a caller to answer a questionnaire, it will look for the questionnaire name specified (seven characters or less), IN CAPS, at the beginning of a line in this file (preceding spaces are allowed). Parameter 76 (default drive) The drive and path where the questionnaire files are located. Parameter 77 MAIN.PUI The path and filename of the "Programmable User Interface" to be used. See section 7.6 for a fuller description of RBBS-PC's PUI. CONFIG will add the extension ".PUI" to this file. If this file is not found, RBBS-PC uses the standard interface. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-10 Parameter 78 YES Specifies whether RBBS-PC should insert page-breaks in menus. Normally, you will want RBBS-PC to insert page-breaks when needed, unless you have written "full-screen" menus which do ANSI cursor positioning. In this case, the lines in the menu files may not accurately reflect the lines used on the callers screen. Parameter 79 (default drive) The drive and path where RBBS-PC macros are stored. Parameter 80 <none> The extension for RBBS-PC macro files (usually .MCR). See section 7.8 for a full description of RBBS-PC's macro capabilities. 10.5 Parameters for RBBS-PC System Files (part 2) ------------------------------------------------- Parameter 81 TRASHCAN The path and filename of the "illegal name" file. This file is used when a new user signs on. The new users first and last name are each individually checked against the names in this file, as well as the entire name. The format of this file is as follows: <name>, An example of such a file would be: BITE, BYTE, PAPA DOC, DOCTOR, DEATH, GLADIATOR, KILLER, MAN, THE The comma is optional after each name. However, it does help in delineating exactly what character strings are being searched for and compared against (some text editors may add extraneous and non-visible characters to a line). All names should be UPPER CASE! If the above file existed, any new user who logged and used the following names would be denied access: Byte Killer Kilo Man Doctor Death PC Doctor Pappa Doctor but "Hoppa Pappa" would be fine. Parameter 82 <none> The path and filename of the "required" questionnaire. RBBS-PC records in the users record when the required questionnaire is answered so that it will only ask each caller once. Both first-time and old callers will be required to answer this questionnaire. When you install a new required questionnaire, use CONFIG parameter 186 to USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-11 mark all user records so they will once again be required to answer the questionnaire. NOTE: Parameter 82 allows you to specify a path. RBBS-PC will not automatically look in the path specified in parameter 76. Parameter 83 PRELOG The path and filename displayed to callers as soon as carrier is detected and BEFORE a user can log on. It is displayed immediately after the name of the RBBS-PC is shown (see parameter 12). SysOps should use this file to convey such information as whether real names are required, 300 baud users will automatically be denied access, etc. Parameter 84 RBBS-REG.DEF The path and filename of the optional questionnaire RBBS-PC will require new users to answer on their first call. See section 19 for details on RBBS-PC questionnaires. Parameter 85 EPILOG.DEF The path and filename of the optional questionnaire RBBS-PC will ask each caller when they log off each time from your RBBS-PC (see section 19). Parameter 86 MESSAGES The path and filename of the RBBS-PC message file. This file contains all messages entered by callers, as well as configuration data. If this file does not exist when you run CONFIG, CONFIG will ask if it should create the file. NOTE: Read section 18 if you want to include the main message file in the scan for conference mail waiting. Parameter 87 USERS The path and filename of the RBBS-PC USER file. This file is where RBBS-PC keeps track of the name and profile for each caller. Parameter 88 COMMENTS The path and filename where RBBS-PC will store comments that callers leave to the SysOp. Even if comments are recorded as private messages (see parameter 89), you should specify a COMMENTS file, since RBBS-PC will place comments here if the MESSAGE file is full. RBBS-PC will automatically create the COMMENTS file when needed. Parameter 89 NO allows SysOps to have comments recorded as private messages to them in the main messages file providing there is any room. This allows replies to comments to be done much more easily. Parameter 90 CALLERS The path and filename for RBBS-PC's CALLER log. RBBS-PC will create this file, and log the date and time of each caller to the BBS. Information such as uploads and downloads, security violations and communications parameters are also logged. SysOp function 2 will display this information. Parameter 91 NO Specifies that RBBS-PC should log the following additional information in the callers log: 1) Connect not completed 9) Left comment at time RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-12 2) Sleep disconnect 10) Logged off at time 3) Caller changed name/address 11) Carrier dropped at time 4) Newuser 12) Message # xxxx left at 5) Bulletin x read 13) Read Messages ... 6) SysOp initiated Chat 14) Answered questionnaire xxx 7) Entered Conference/Sub-board x 15) Killed msg # xxxx 8) Time limit exceeded NOTE: Each CALLER log entry uses 66 bytes of disk storage. Using parameter 91 can provide useful information, but you should monitor the size of your CALLER log so it does not consume your entire disk! Parameter 92 has not been implemented in RBBS-PC. Parameter 93 CONFMAIL.DEF The path and filename for the conference mail-scan file. This file tells RBBS-PC which conferences should be checked when a caller wants to scan for new mail. The format of this file and the flexibility it affords the RBBS-PC SysOp is described more fully in section 18. Parameter 94 30 The maximum number of "working variables" that RBBS-PC allocates for questionnaires and macros. A "working variable" is simply a place in which RBBS-PC can store a response or a set of characters. These "working variables" can then be used to create parameters that can be passed to "DOOR"s (see section 14.3) or written out to data bases (see section 7.8.4). 10.6 Parameters for RBBS-PC "Doors" ----------------------------------- Parameter 101 NO Activates the DOOR function. See section 14 for a complete description of the RBBS-PC door subsystem. Parameter 102 MENU5 The path and filename of the DOOR menu, which RBBS-PC will show to the caller when a list of doors is requested. Before RBBS-PC will allow a caller to open a door, it will look for the door name specified (seven characters or less), IN CAPS, at the beginning of a line in this file (preceding spaces are allowed). Parameter 103 RCTTY.BAT The path and filename of the .BAT file RBBS-PC should create when building a "door" exit. The batch file that invokes RBBS-PC must check if this file exists whenever RBBS-PC terminates and (if it exists) execute it (see section 13). This is also the same file name that is used when the SysOp exits to DOS. Parameter 104 RBBS.BAT The path and filename of the .BAT file used to start RBBS-PC. This is used to re-invoke RBBS-PC after a door (see section 13). This is also the same file name that is used when the SysOp returns from exiting to DOS. Parameter 105 C:\ The DOS subdirectory where RBBS-PC can find the DOS command processor (COMMAND.COM). This is also the location for the .BAT files which test and convert compressed uploads. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-13 Parameter 106 YES The method used to redirect I/O when dropping to DOS as a remote SysOp (command "7"). Answering YES selects the standard DOS "Change Console Command" (CTTY), NO selects the DOS redirect function (">" or "<"). This parameter allows you to specify if the redirected output is to be handled by a SysOp-supplied device driver. If you don't elect to use a special device driver, RBBS-PC will redirect the output directly to the communications port by building the command "CTTY COMx" or ">COMx and <COMx" , where "x" is based on the communications port the node was configured for. If you specify the name of a device driver, RBBS-PC will build the command CTTY [driver name]. Parameter 107 <none> The path and filename of a program (i.e. an .EXE or .COM file) that is to run when a new users logs on. This feature is intended for those who feel the need to perform an extensive verification of new users that is not met by RBBS-PC's built in scripting capability or automatic subscription functions. Parameter 108 0 Allows the external program designated via parameter 107 to be invoked for not only new users, but also for callers who have a security level equal to or less than the security level specified in parameter 108. Parameter 109 DOORS.DEF The path and filename of the "DOORS" control file. See section 14.3 for more information. 10.7 Parameters for RBBS-PC's Security (part 1) ----------------------------------------------- Parameter 121 SECRET NAME The first and last name of the SysOp pseudonym. It is this name that causes RBBS-PC to recognize the remote caller as the SysOp and not simply a user with a security level equal to that of the SysOp. This should be a first and last name combination that is not likely to be selected by other callers. The name supplied in parameters 1 and 2 cannot be used by ANYONE to log on. If the SysOp wants to log on remotely, the name in parameter 121 must be used. Parameter 122 NO If YES, specifies that a LOCAL logon (via the ESC key) should logon as the SysOp automatically. NO will prompt for a name before allowing anyone to log on locally. Parameter 123 0 The minimum security level users need in order to log onto RBBS-PC. Callers with a security level less than this number will be given an "ACCESS DENIED" message and immediately disconnected. Parameter 124 5 The security level assigned to new users. If this security level is less than the minimum security level to log on, no new users can log on. This means that no new users are allowed and access is limited only to pre-registered users. Parameter 125 10 The minimum security level a user must have in order to be considered a SysOp. Even if a user has a high enough security level to see the SysOp menu and execute some or all of the SysOp commands, the user RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-14 will not be treated as a SysOp (i.e. allowed to see the files upload/download when viewing the CALLERS file) unless the users security level is equal to or greater than that specified by this parameter. Parameter 126 10 The minimum security level required to see the SysOp menu. This does not give a user SysOp access, it only allows him to see the menu of SysOp commands. Parameter 127 10 The minimum security level a user must have to leave an extended (i.e. multiple line) description of a file that was uploaded. See parameter 40 for the maximum number of lines that an extended description will be allowed to have. Parameter 128 5 The maximum number of security violations (i.e. attempts to download protected files) before the user is logged off and locked out. Parameter 129 10 The minimum security level to access each SysOp function. These may all be set to the same level, or each command can have a different minimum security level. Parameter 130 <variable> The minimum security level to access the MAIN commands. These may all be set to the same level, or each command can have a different minimum security level. Parameter 131 <variable> The minimum security level to access the FILE commands. These may all be set to the same level, or each command can have a different minimum security level. Parameter 132 5 The minimum security level to access the UTILITY commands. These may all be set to the same level, or each command can have a different minimum security level. Parameter 133 <variable> The minimum security level to access the GLOBAL commands. These may all be set to the same level, or each command can have a different minimum security level. Parameter 134 3 The maximum number of times a user can change their password in a given session. This prevents a caller from "fishing" for special passwords. Parameter 135 5 The minimum security level required in order for users to access privileged group passwords. If the user's security is less than this level, ALL password changes that they make will be permanent -- even if the password they select is in the temporary password file named in parameter 146. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-15 Parameter 136 10 The minimum security level required to overwrite on uploads. Users with this security level can REPLACE EXISTING FILES by uploading a file with the same name. Parameter 137 10 The minimum security level "exempt" from packing. When the SysOp packs the user file, callers with this security level or greater will NOT be removed from the user file, even if they have not called in the number of months specified in parameter 11. Parameter 138 5 The default security level of new PRIVATE messages. Only those with this security level or higher can read new private messages -- even if they have been addressed to them. This allows the SysOp to "preview" messages, and then lower the security level of each message so that the addressee can read it. Parameter 139 5 The default security level of new PUBLIC messages. Only those with this security level or higher can read new public messages -- even if they have been addressed to them. This allows the SysOp to "preview" messages, and then lower the security level of each message so that the every user can read it. Parameter 140 10 The minimum security level required to change the security level of a message. 10.8 Parameters for RBBS-PC's Security (part 2) ----------------------------------------------- Parameter 141 is not implemented in RBBS-PC. Parameter 142 <default dir> The drive and path where the "personal" files are located. If a file listed in the directory is not found here, the download drives will then be searched, so it is not necessary to have a copy of a file here in order to use personal downloads. However, files in this directory can be protected so that ONLY personal download will access the files. Parameter 143 PRIV.DEF The name of the "personal directory." If no extension is specified, ".DEF" will be used. If not path is specified, the path in parameter 142 will be used. Parameter 144 <none> The default protocol to be used when downloading personal files. If no protocol is specified, the "P" command behaves exactly same as the D)ownload command. If a protocol is specified, it will be used unless overridden by the command line (i.e. "P file.ext Z"). Parameter 145 FILESEC The path and filename of the "file security" list. See section 15.4 for more information. Parameter 146 PASSWRDS The path and filename which contains the privileged group passwords and security-level limits. See section 15.3. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-16 Parameter 147 NO Specifies that multi-file personal downloads using ASCII should be done "non-stop." This is useful if the SysOp wants users to download to a continuous feed printer. Parameter 148 10 The minimum security a user must have in order to "categorize" uploads when the SysOp is using the File Management System (FMS). Uploads by callers with insufficient security to categorize will be placed in the default "upload" category. Parameter 149 5 The minimum security to view NEW uploads. RBBS-PC will omit either ALL files in the "upload" directory, or only those files in the "upload" category (if the upload directory is the master FMS directory). Parameter 150 6 The minimum security to bypass the "epilog" questionnaire, specified in parameter 85. Parameter 151 5 The minimum security level required to automatically add a user to a conference. This parameter is only activate when CONFIG is in "conference maintenance" mode (see parameter 167). If a caller tries to join a conference, they will be denied access unless they are already a member, or their security is at or above this level. Each conference may have a different setting for this parameter. NOTE: Sub-boards do NOT use this feature. To restrict access to a Sub-board, use parameter 123. Parameter 152 6 The minimum security level for a caller to "turbo logon". This feature allows a caller to go DIRECTLY to the main menu, bypassing the welcome, new upload and bulletin displays. To use "Turbo logon", the user must answer the "What is your FIRST name" prompt with: firstname lastname password ![conference] The "!" after the password signals RBBS-PC to use "turbo." If the conference name is omitted, the caller will be left in the MAIN conference. If the caller substitutes a "$" for the "!", Only the WELCOME will be bypassed. This is helpful for systems with extensive ANSI welcome screens that can be tedious for old callers. Parameter 153 10 The minimum security required by a caller to add a description for an existing file. Typically this is restricted to the SysOp only. It can be used by the SysOp to create FMS directories. After placing the files in the upload subdirectory (or anywhere in the download path) the SysOp can use RBBS-PC to add descriptions for the files. RBBS-PC will first ask if you wish to OVERWRITE the file. If you answer NO, RBBS-PC will then ask if you wish to add a description. In this way, RBBS-PC will properly build the directory entry. Parameter 154 SECVIO.HLP The name of the help file that is shown to a caller whenever the caller incurs a security violation. RBBS-PC will add the HELP directory and EXTENSION (from parameters 64 and 66). USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-17 Parameter 155 <none> Denies callers access to one or both of RBBS-PC's "premium features -- DOORS and file downloading, for a specific period of time. This can be used to direct the callers' attentions to other features of RBBS-PC (such as message bases). The PASSWRDS file (see section 15.3) specifies how many SECONDS the caller must be online before the premium features are available. If a caller tries to use a locked feature before the time has elapsed, the caller will be given a message and denied access. This is *NOT* recorded as a security violation. The file TIMELOCK.HLP should be placed with the other RBBS-PC HELP files. This file (if found) will be shown to a user who is locked out of a command. If the TIMELOCK.HLP file is not available, the caller will be given a "canned" message: "Sorry, (name), try that function later." Parameter 156 10 The minimum security to be exempt from automatic security updates. If the caller's MAIN security level is changed, their security level in conferences will also be changed if their security in the conference is less than this setting. This allows the SysOp to adjust their security in the MAIN conference, and RBBS-PC will make the adjustments in each conference and sub-board. If the SysOp increases a caller's security in a conference (to make them a "SIGOp"), The caller will maintain this increased security only if it is above this setting. Parameter 157 10 The minimum security a caller must have to be able to read and kill all messages (in the message base for which this is a .DEF file). This allows the SysOp to create an "assistant MESSAGE SysOp" who can police message traffic, without granting that user full SysOp privileges. Parameter 158 SEEN-BY: Specifies a text string that, if found at the start of a message line, will NOT be shown to the caller. This can be used to hide the sometimes enormous network routing data found in network mail. 10.9 Parameters for Multiple RBBS-PC's/Conferences -------------------------------------------------- Parameter 161 1 The maximum number of RBBS-PC nodes. Up to 36 RBBS-PC's can share the same files. Different environments have different maximum number of nodes that they can effectively support. Setting this parameter configures the MESSAGE files so they contain the appropriate number of "node" records. Parameter 162 DOS The environment that multiple copies of RBBS-PC will be sharing files in. This is necessary so that RBBS-PC can use the mechanism that is appropriate to the specific environment when sharing files. RBBS-PC currently can handle the following environments for multiple RBBS-PC's: 0) Single node under DOS 1) MultiLink (The Software Link, Inc.) 2) OmniNet (Corvus) 3) PC-Net (Orchid) 4) DESQview (Quarterdeck Office Systems) RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-18 5) 10 Net (Fox Research) 6) IBM's NETBIOS NOTE: Many manufacturers utilize Orchid's network conventions. As an example, AST and Alloy are both vendor's whose "network" is .EXE file- compatible with Orchid's. If you have a network of PC's, check with the vendor to see how compatible their network is with those supported by RBBS-PC. Parameter 163 INTERNAL Specifies the method RBBS-PC uses to recycle after a call. INTERNAL recycling is done within the RBBS-PC.EXE file. SYSTEM recycling exits RBBS-PC, and expects the invoking .BAT file to recycle. Internal is faster, but System allows an external event to be processed after each caller. Parameter 164 8 The number of records in the USERS file. This number must be an even power of 2 (256, 512, 1024, 2048, etc.). When the USER file is almost full, the SysOp will either have to "rebuild" the user file (see parameter 182) or increase this file size. The SysOp can check on the freespace in this file with the RBBS-PC "statistics" command (UTIL section). Parameter 291 lets new users on even if the users file is full. Parameter 165 27 Specifies the default number of records in the MESSAGES file. Each file is 128 bytes. The number of messages that can be stored is a function of the number of lines allowed per message. The minimum size of the MESSAGES file is equal to 1 (The "checkpoint" record) plus the maximum number of concurrent RBBS-PC's ("node" records) plus the maximum number of messages allowed multiplied by 5 (each messages is assumed to average five 128-byte records) Parameter 166 5 The maximum number of messages allowed in the message file at any one time. The absolute upper limit on the number of messages is 999. If you specify 250 messages, you can expect that the MESSAGES file will be formatted to more than 160K in size. If you allow the message file to grow (parameter 170), only parameter 166 will limit the growth of the file. If your message file does not grow, both the number of messages, and the number of records will limit how many messages can be left. Parameter 167 Enters "conference maintenance" This allows you to set features or do maintenance on CONFERENCES (not Sub-boards!). You will be asked for the conference name, which can be up to 7 characters (CONFIG will add an "M" to the conference MESSAGE filename, and a "U" to the USER file name). While in conference maintenance mode, you can create conference message and user files, perform maintenance on them, or set conference variables (see parameter 151. To perform maintenance on a Sub-board, you should start config with the sub-board .DEF file (i.e. CONFIG MYSUBC.DEF). If you change the size of a conference MESSAGE or USER file, the change will take place when press the END key while in conference maintenance mode. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-19 Parameter 168 ZIP The default file extension for uploads and downloads. If a file is UPLOADED, and the user does not specify an extension, this default will be used. If a file DOWNLOAD request does not specify an extension, the default will be used. In order to upload files with NO extension, a "." must follow the name (i.e. U MYFILE. Z). Parameter 169 <none> Additional file extensions in addition to the default, to search when looking for an uploaded file, to decide if it is already present. A file will be considered already in the catalog if the prefix matches. Warning: this search can be time consuming unless you have installed the Fast File Search. Every extension listed should begin with a period. E.g. ".ARC.PAK" would count an upload of XYZ.ZIP as a duplicate if the file XYZ.PAK or XYZ.ARC exists. Parameter 170 NO Allows the MESSAGE files to "grow." If the limit on active messages (parameter 166) has not been exceeded, and the number of records has been exhausted, RBBS-PC will increase the size of the message file to accommodate more messages. NOTE: The Corvus Network software does not allow a message file to grow. 10.10 RBBS-PC SysOp Utilities ----------------------------- Parameter 181 Packs the message base. When a message is "killed," the space used by that message is not freed (this allows a message to be "resurrected). Parameter 181 makes a backup of the message file, then reclaims the space used by killed messages. Parameter 182 Removes deleted users and users who have not been on the system within the number of months specified in parameter 16. You should have enough free disk space for a second copy of the users file (with a qualifier of ".BAK") or the rebuilding will terminate abnormally (the users file will be restored). NOTE: Locked-out users (security less than 0) will not be removed from the file. Parameter 183 Displays the message headers of all messages, active and killed, that are present in the message file. This is left over from one of the many "debugging" stages of RBBS-PC prior to CPC09. Following the policy of making all changes "additive", this function has been retained. It may help some SysOps recover from disk hardware failures. Parameter 184 Renumbers messages. An RBBS-PC message number cannot be higher than 9999. This function will renumber the active messages, utilizing numbers once used by deleted messages. Also, each caller's high- message pointer will be updated to reflect the renumbered message. Parameter 185 Scans the message file and reconstructs the chains that link the messages together. Message files that have "blank" messages or abbreviated messages (i.e. some lines of text are missing) can be repaired with this facility. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-20 Parameter 186 Sets a flag in all USER records that will require the user to answer the required questionnaire (see parameter 82). Parameter 187 Scans the FMS directory to be sure each record conforms to the exact format required by the FMS (in case the text editor used by the SysOp to edit the file inserted tabs or shorten lines that had trailing blanks at the end of them). Parameter 188 Scans the PERSONAL download directory to be sure the format is proper for a PRIV.DEF file. Parameter 189 This parameter will guide the SysOp, sequentially, through only those parameters that would normally have to be changed when setting up a new RBBS-PC. Parameter 190 This parameter will guide the SysOp, sequentially, through the parameters that are new and/or changed for the current release of RBBS- PC. Parameter 191 Will turn the "printer enabled" flag off in all the node records. This is useful if somehow the printer is accidentally enabled, but no printer exists (a condition which will halt RBBS-PC). Parameter 192 Scans the USER file and turns the "highlight" feature off for any user who did not select COLOR. This will rescue confused callers from the problem of receiving ANSI sequences when their terminal does not support ANSI. 10.11 RBBS-PC's File Management System Parameters ------------------------------------------------- Parameter 201 C: The drive letter where uploads should be placed. Enter only the DRIVE letter here. The exact subdirectory can be entered in parameter 208. Parameter 202 99 The name of the directory file where RBBS-PC should place upload descriptions. This upload directory can be the master FMS directory, or a separate upload directory. Parameter 203 C: The drive/path were the upload directory is to be found. Parameter 204 C The letters of the drives from which files can be downloaded. The order in which they are specified is the order in which the drives will be searched. If the order is BAC, then drive B will be searched first for the file, then drive A, and finally drive C. While there can be duplicate files on each of the drives, the first file found will be the one downloaded to the user. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-21 Parameter 205 NO Specifies that DOS subdirectories are used. This is a reflection of RBBS-PC's early history (before DOS supported subdirectories) and should always be set to YES. Parameter 206 NO Specifies that uploads are to be sent to DOS subdirectories. This is a reflection of RBBS-PC's early history (before DOS supported subdirectories) and should always be set to YES. Parameter 207 NO Specifies that downloads are separated into DOS subdirectories. This is a reflection of RBBS-PC's early history (before DOS supported subdirectories) and should always be set to YES. Parameter 208 Specifies the DOS subdirectory where UPLOADS are placed, and a list of subdirectories where DOWNLOADS are searched. This is only functional if you have responded "Yes" to either parameter 206 or parameter 207. The FAST FILE SEARCH can be used in conjunction with this directory list to find downloads (see section 12.9). Parameter 209 DIR The file extension for RBBS-PC directory files. Parameter 210 <none> An alternative extension to be used for "directory" files. The main use for an "alternate" extension is to allow "sub-boards" to share directories using the main extension (parameter 209), but also have some directories unique to the "sub-board" that are not shared with others. Parameter 211 DIR The name (prefix only) of the directory of directories. This file lists either the names of other .DIR files, or FMS category codes (see section 12). Parameter 212 NO Allows the SysOp to exclude the directory of directories from the search done by the New command. If your directory of directories does not contain FILE descriptions, but only directory descriptions, you will probably not want it searched by the "new" command. Parameter 213 NO Specifies an additional file to place upload descriptions. This could be used to maintain a downloadable list of ALL files, or a bulletin of NEW uploads. Parameter 214 <none> The name (without path or extension) of the master FMS directory. See section 12.3 for a full description of the advantages of using FMS Parameter 215 NO Limits the search for directories to the master FMS directory. If you have multiple .DIR files, set this parameter to NO. If you only use FMS, set this parameter to YES to increase the speed of directory searches. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-22 Parameter 216 UNC The default category code for uploads. This parameter is how uploads get classified in the FMS directory if the uploader does not have sufficient security to categorize an upload. If this category is "***," only the SysOp will see the new upload. Parameter 217 DIR.CAT The name of the file which tells RBBS-PC what categories are included in the FMS directory. The format of the file is described in section 12.5. Parameter 218 NO Specifies what directories will be listed in a request for "all" directories. This parameter is REQUIRED in order for "all" to be defined as an option. Begin with "@" if you want to specify a list of directories. For example, "@C:\RBBS\ALLDIR.LST" means that the text file "ALLDIR.LST" on drive C in subdirectory ALLDIR contains a list of directories to search when "all" is specified. The directories in ALLDIR.LST should use the same names as the caller would type in, one to a line. E.g. if "all" is the search directories 1,3, and 4, ALLDIR.LST should contain 1 3 4 You can also specify a specific directory to confine all to by including an entry not beginning with "@", e.g. "FMS" would list directory FMS.DIR, located in the drive/path specified where directory files go. If you want to disable the search for "all", just press Enter in response to this parameter. Parameter 219 40 The maximum length of the description that can be given to an uploaded file. RBBS-PC can be configured so that those who upload files can provide a description of the file they upload. This description informs others what the file does and helps them decide whether they want to download the files. The maximum length of the description can be set to any value between 40 and 46. WARNING: If you change this option, you must manually change all existing directories. Parameter 220 C: The drive and directory where all directory files must be put, except possibly for the upload directory. Only in this DOS directory does RBBS-PC look for RBBS-PC directory files, with the sole exception of the upload directory when the caller's security level permits the upload directory to be viewed (see parameter 149). 10.12 Communications Parameters (part 1) ---------------------------------------- Parameter 221 COM1 The communication port that RBBS-PC will use. If you specify COM0, RBBS-PC will run in "local" mode, allowing you to run RBBS-PC without a modem. RBBS-PC can support COM1 and COM2 directly, or it can support a FOSSIL driver, and thereby support any communications port supported by the FOSSIL. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-23 Parameter 222 3 The number of seconds that RBBS-PC should wait after initializing the modem with a "reset" command. Many modems require only 1 second to reset, however some may require much (MUCH) longer. Parameter 223 1 The number of seconds to wait prior to issuing a modem command. This is most useful when you have configured RBBS-PC to only issue commands between rings and want the modem to "settle down" after a ring has ended. If you find that 2400 baud calls are improperly connected at 1200 baud, increase the wait. Some modems take longer to connect at 2400 than at lower speeds. Parameter 224 1 The number of rings to wait before answering the phone. Specifying zero rings means that the modem (not RBBS-PC!) will answer the phone as soon as it rings. NOTE: RBBS-PC's control of answer mode is an important part of its security. Setting parameter 224 to ZERO bypasses this security! If you specify one or more rings, the modem must be able to tell RBBS-PC when the phone is ringing (via RS-232 pin 22 or the "RING" response string). The modem must also be able to count rings in its S-registers. You can also specify "Ring-Back." This instructs RBBS-PC to IGNORE a ringing phone, but if the phone stops ringing (for more than 10 but less than 45 seconds) and then starts ringing again, RBBS-PC will answer. This is useful for non- dedicated phone lines, or hearing-impaired SysOps who want to use both TDD (telecommunications device for the deaf) and RBBS-PC. A caller who wants the SysOp to use TDD will let the phone ring until the TDD connects, but will call, let the phone ring once then hang up, and then call BACK to get RBBS-PC to answer the phone. Parameter 225 Sets the commands RBBS-PC uses to communicate with the modem. A list of SysOp-supplied settings for various modems is also available (See section 11). Parameter 226 Activates software-based MNP support. This option is no longer available, unless Microcom can supply a library that is compatible with current Microsoft BASIC compilers. RBBS-PC does support MNP protocol that is hardware-based (i.e. built into the calling and answering modems). Parameter 227 NO Restricts RBBS-PC so it will only issue modem commands BETWEEN rings. Some modems cannot handle the telephone ringing and accept modem commands simultaneously. Most modems do NOT require this restriction. Parameter 228 300 The speed RBBS-PC should initialize the modem to. Most modems will only REDUCE speed when automatically detecting baud rate, so this value should be set to the maximum speed supported by your modem. Parameter 229 180 seconds The number of seconds RBBS-PC will wait before disconnecting an "idle" caller. If a caller walks away from an RBBS-PC session, RBBS-PC will first warn the caller, then disconnect the call after the specified number of seconds. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-24 Parameter 230 NO Specifies a "dumb" modem is being used. Selecting this means that no modem commands are sent from RBBS-PC to the modem. This can be used to connect RBBS-PC to a communications network (i.e. TymNet) or local area network that supplied a simple RS-232 interface. Selecting this option causes RBBS-PC to - Issue no Hayes commands, - Depend on no Hayes-like responses, - Control the interface with the Data Terminal Ready (DTR), - Assume somebody has called whenever Carrier Detect (CD) is detected, and - Assume that whomever calls is at the baud rate selected in CONFIG parameter 228. Parameter 231 Initializes the modem's firmware for use by RBBS-PC. The commands used to perform firmware initialization can be modified with parameter 225. Parameter 232 3 The number of seconds to wait after dropping DTR (Data Terminal Ready). RBBS-PC drops DTR in order to disconnect a caller. Too short a delay will cause the modem not to re-initialize properly. Parameter 233 PROTO.DEF The path and filename of the external protocol driver file (see section 20). Parameter 234 NO Activates RBBS-PC's check for AutoDownload support (supported by the PC-TALK terminal emulator) at the start of each call. This check is incompatible with some terminals and communications packages, causing them to stop displaying on the local screen. The caller can control whether autodownload is used with the T)oggle command in utilities. It is recommended that this option NOT be enabled. Parameter 235 YES Instructs RBBS-PC to force downloads with "binary" file extensions (i.e. .ARC, .ZIP, .EXE, .COM, .OBJ, .WKS, .BAS, or whose second letter of the extension is Q) to non-ASCII protocols. Parameter 236 <don't recycle> Instructs RBBS-PC to "recycle" after a number of minutes passes without receiving a call. This may help recover from a modem malfunction. Set this value to the number of minutes an "idle" RBBS-PC could mean a modem problem. Specifying 0 means that RBBS-PC will not re-cycle, no matter how many minutes elapse between calls. Parameter 237 NO Forces RBBS-PC to leave the modem at the baud rate it was initially opened at rather than automatically matching the baud rate of the caller. RBBS-PC normally changes the baud rate in the RS-232 interface to match that of the callers. Some modems allow RBBS-PC to transfer at maximum speed on all calls, while the modem handles the speed conversion. In this case you would set parameter 237 to YES. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-25 10.13 Communications Parameters (part 2) ---------------------------------------- Parameter 241 NO Instructs RBBS-PC to switch back to the original parity/word length setting after a binary transfer. If a caller using 7bit, even parity requests a binary transfer, RBBS-PC will switch to 8bit, no parity. Parameter 241 controls whether RBBS-PC stays at 8bit or reverts to 7bit after the transfer. Most environments can remain at 8bit after a transfer. Parameter 242 0 Specifies the minimum modem speed that new callers can have. If a new caller connects at a speed less than that specified, RBBS-PC will deny access to that caller. Parameter 243 0 Specifies the minimum modem speed for OLD callers. With this parameter, you can block any NEW callers at 300bps, but allow a pre- registered caller access at that speed. Parameter 244 NO Activates CTS (clear to send) and RTS (request to send) flow control. This hardware flow control uses RS-232 pins 4 and 5 to control the flow of data between RBBS-PC and the modem. Parameter 245 NO Activates XON/XOFF flow control. This software flow control uses ASCII codes to control the flow of data between RBBS-PC and the modem. NOTE: RBBS-PC only supports XON/XOFF at the end of each buffer. If RBBS-PC is to quickly respond to XON/XOFF, set parameter 54 to a small number. Parameter 246 30 The maximum time to RBBS-PC should wait for carrier after answering the phone. 10.14 Parameters for RBBS-PC NET-MAIL ------------------------------------- Parameter 261 <none> Specifies the time of day in HHMM format at which RBBS-PC is to perform a "daily event." At this time, RBBS-PC will create a "daily event" signal file, and exit to DOS. The signal file is in the form "RBBS?TM.DEF", where ? is the node number. See section 13 for a complete description of the requirements for .BAT files when doing daily events. Parameter 262 <none> Selects a network "front end" for use with RBBS-PC. Currently, RBBS-PC supports the following front-ends: SeaDog and BinkleyTerm (see Appendix S). By enabling this option, the SysOp assumes the responsibility of configuring the "net mail" application to: 1. answer the phone and determine if the caller is sending "net mail". 2. if the caller is not sending "net mail", the net mail application must invoke RBBS-PC with the following command line: RBBS-PC.EXE nodeid filename /time /baud /RELIABLE RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-26 where: - "nodeid" is the node ID in the range 1-9, 0, or A-Z. - "filename" is the fully qualified file name to use as the RBBS-PC ".DEF" file. - "/time" is the time of day for RBBS-PC to return to the "net mail" application that called RBBS-PC. - "/baud" if the baud rate that the caller dialed in at. - "/RELIABLE" tells RBBS-PC whether the connection has error correction built into the connected modems Parameter 263 <none> The command to turn on intermediate host echo. This is intended to be used when RBBS-PC is connected to a public data network (PDN) as a "node" -- not all systems that people log into on a PDN need be "main frame" computers! When RBBS-PC is a node on a public data network, typically the network will do the echoing -- between the caller and the port they access on the PDN and between RBBS-PC and the port RBBS-PC accesses on the PDN. This causes file transfers to be a problem because the PDN will continue to echo. Therefore it is necessary to be able to go into an "image" mode where data is passed through the PDN intact with no echoing. The contents of this string will be sent AFTER a file transfer so the network will resume echo. Any character can be included in the string using it's decimal ASCII equivalent simply by putting a number inside square brackets. Characters not in square brackets will be transmitted as they were entered. The string "a[32]" will be interpreted as a lower case letter "a" followed by a blank. Parameter 264 <none> The string that sent BEFORE a file exchange that causes the PDN to STOP echoing. As with parameter 263, the contents of this string is entirely dependent on the predilections of the PDN that RBBS-PC is attached to. Parameter 265 RBBS-PC Specifies who should echo characters sent to RBBS-PC. Normally, RBBS-PC echoes back to the caller, but un a PDN, or callers who use TDDs may want to change this value to either an intermediate host, or to the caller's system. Parameter 266 <none> The string RBBS-PC will use to acknowledge each line in an ASCII protocol upload. Typically, an ASCII upload is characterized by two fundamental features -- it contains no unprintable characters and it does not require any "error checking". Under some circumstances a callers communications protocol may require a response from RBBS-PC (i.e. a line feed) before the next line will be transmitted. Parameters 267 FIDX.DEF The path and filename of the FFS (Fast File Search) sorted names file (see section 12.9). Parameter 268 LIDX.DEF The path and filename of the FFS (Fast File Search) "tabs" file (see section 12.9). USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-27 10.15 New Users Parameters -------------------------- Parameter 281 YES Instructs RBBS-PC to allow new callers to set their default system values. RBBS-PC typically asks new users their choice of line feeds, graphics, transfer protocol, and "turbo-key". Sometimes these questions confuse new users, who lack the knowledge to answer them. Parameter 281 Not implemented in this release of RBBS-PC. Parameter 282 Not implemented in this release of RBBS-PC. Parameter 283 Not implemented in this release of RBBS-PC. Parameter 284 Not implemented in this release of RBBS-PC. Parameter 285 Not implemented in this release of RBBS-PC. Parameter 286 Not implemented in this release of RBBS-PC. Parameter 287 Not implemented in this release of RBBS-PC. Parameter 288 Not implemented in this release of RBBS-PC. Parameter 289 Not implemented in this release of RBBS-PC. Parameter 290 YES Specifies new users should be saved in the USER file. If set to NO, new users may log in, but RBBS-PC will not "remember" them on subsequent calls. Parameter 291 Instructs RBBS-PC to allow new users when the USER file is full. In this case, RBBS-PC will not "remember" new callers on subsequent calls, until the USER file is expanded to accommodate more records. 10.16 Use of the Library Sub-System ----------------------------------- Parameter 301 <none> Activates the Library Sub-System (see section 12.6). Specify a drive, which must NOT be a drive used by any other RBBS-PC function. Parameter 302 <default dir> The drive/path where RBBS-PC will find the upper directory (CDR.CDR is the default name). Parameter 303 CDR The file extension that identifies library directory files. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-28 Parameter 304 <default dir> The drive/path of the Library "work disk." This is where the Library sub-system creates archive files for transmission. Normally, 360K of free space is required, so a RAM disk is suitable. Parameter 305 705 The number of disks available in the library. Parameter 306 7 The maximum number of upper level directories that will be found on the Library disk. The PC-SIG CD-ROM is organized with 10 upper level directories, 1-100, 101-200, 201-300 etc. and each of these contain 100 directories, DISK001, DISK002 etc. Parameter 307 100 The maximum number of subdirectories that each upper level directory can contain. Parameter 308 DISK The prefix of the lower level directories. Since the user enters only the disk number that is desired, RBBS-PC creates the subdirectory name based on this parameter and the number entered. Parameter 309 MENU6 The drive\path\name of the Library Sub-system menu. Parameter 310 The list of command symbols that are available from the Library Sub-System menu. Parameter 311 <variable> The security values related to the symbols listed in parameter 310. Parameter 312 <default dir> The drive\path where the archive utility program can be found. Parameter 313 ARCA The archive utility that will do the archiving on Library disks. When answering the questions to this parameter you will also be asked what the CREATE parameter is. For PKARC and ARC the correct response is "A". If using ARCA there is no CREATE parameter since CREATE is the only function that it can do. 10.17 RBBS-PC's Parameters for Color ------------------------------------ Parameter 321 [27][1;41;37m The string that turns ON highlighting or emphasizing of characters in text strings displayed to the caller (see section 7.10). Parameter 322 [27][0;40;33m The string that turns OFF highlighting or emphasizing of characters in text strings displayed to the caller. Parameter 323 Bright Green Foreground color 1. The SysOp can select this color in menus and text by using the SmartText command C1. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-29 Parameter 324 Bright Yellow Foreground color 2. The SysOp can select this color in menus and text by using the SmartText command C2. Parameter 325 Bright Purple Foreground color 3. The SysOp can select this color in menus and text by using the SmartText command C3. Parameter 326 Bright Cyan Foreground color 4. The SysOp can select this color in menus and text by using the SmartText command C4. Parameter 327 <none> The background color used against the preceding four foreground colors. MODEM SWITCH SETTING AND CONSIDERATIONS 11-1 11. MODEM SWITCH SETTING AND CONSIDERATIONS ------------------------------------------- Recognizing that there are many "Hayes-compatible" (and not so compatible) modems in use, this section is intended to assist those adventurous souls who wish to properly configure a modem for use with RBBS-PC. By explaining what RBBS-PC expects from a modem, we hope you can determine how to set your modem to provide what RBBS-PC expects. There are three levels of modem configurations: 1) Hardware switches. These are physical switches that can be turned on or off to control modem functions. RBBS-PC tries NOT to rely on these switches, since other software you use may require different settings. Many modems have software overrides for these switches, and RBBS-PC will use them when possible. If your modem has hardware switches, you will want to concentrate on them first. Find out what functions are selected by switches that CANNOT be overridden by firmware or software commands. 2) Firmware switches. These are software commands that you can issue to the modem, and then tell the modem to "remember" these settings, even after the modem is powered off. RBBS-PC tries NOT to rely on these switches, for the same reason it avoids hardware switches. However, there are usually switch settings that must be set for use with RBBS-PC. 3) Software commands. These are "temporary" commands sent to the modem, that will be erased when the modem is turned off. RBBS-PC does most of the configuration via software commands, to allow the most flexibility in modem operation. RBBS-PC requires a modem to provide certain functions to ensure proper operation. By studying these requirements, you should be able to find a combination of hardware, firmware and software settings to satisfy all these needs: - Modem result codes. Most modems offer both verbose and numeric results to modem commands. RBBS-PC expects VERBOSE codes, as in: RING When the phone is ringing CONNECT When carrier is established CONNECT 2400 MNP When a reliable 2400 bps call is established. - Carrier Detection. RBBS-PC expects the modem to raise and lower the CARRIER DETECT signal (RS-232 pin 8) to properly reflect the presence of a caller. - Data Terminal Ready. RBBS-PC expects the modem to properly respond to DTR. When RBBS-PC turns DTR off, any call should be terminated and the modem should reset. - Ring counter. RBBS-PC expects the modem to count the number of times the phone rings, and provide this count when a "count modem rings" command is sent. CONFIG parameter 225 allows the SysOp to set modem commands use by RBBS-PC. The commands that you can set are: RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 11-2 1) RESET THE MODEM. This command is sent when RBBS-PC wants the modem returned to its initial configuration (including any changes saved in firmware). Normally, the command used is: ATZ 2) INITIALIZE THE MODEM. This is the SOFTWARE initialization, used by RBBS-PC each time it recycles. Any commands needed to put your modem into "RBBS-PC mode" should go here. For generic Hayes-compatible modems, the command would be: ATE0M0Q0V1X1S0=254S2=255S10=20 The sub-command S0=254 is important to this string. RBBS-PC uses this to control how it answers the phone. Use: S0=001 to answer on 0 rings S0=254 to answer on 1 or more rings, no ring-back S0=255 to answer on 1 or more rings, with ring-back 3) COUNT RINGS. RBBS-PC uses this command to ask the modem how many times the phone has rung. For Hayes-compatible modems, this command should be: ATS1? 4) ANSWER PHONE. RBBS-PC uses this command to tell the modem to answer the phone. This is normally: ATA 5) TAKE PHONE OFF HOOK. RBBS-PC uses this command to "busy the line" when recycling, or when the SysOp drops to DOS when the node is idle. This is normally: ATH1M0 6) CLEAR FIRMWARE. This command is used to reset the modem's firmware to "factory defaults." CONFIG uses it before programming the modem's firmware. Normally, this is: AT&F 7) INITIALIZE FIRMWARE. This command sets any firmware settings that are needed to satisfy RBBS-PC's modem requirements. The settings will vary greatly from modem to modem. 8) WRITE MODEM'S FIRMWARE. This command is used to make the settings in command 7 permanent. Usually, this is: AT&W Appendix D contains configuration for several modem brands. This information may serve as a guide to configuring your modem. If you make any discoveries about the interaction between your modem and RBBS-PC, please share them with the RBBS-PC authors, so that the information can be given to others. RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-1 12. RBBS-PC's FILE MANAGEMENT SUBSYSTEM --------------------------------------- The File Subsystem allows RBBS-PC to maintain a list of files available for downloading. Users can list files by date, category, or by using a search argument. RBBS-PC refers to a file that contains a list of files available for downloading as a "directory" (i.e. a .DIR file). This should not be confused with DOS "subdirectories." There are two ways to configure the File System. One is to have simple "directory" files. The other is to have a FILE MANAGEMENT SYSTEM (FMS) file that contains the names, sizes, dates, and description of all the files available for downloading. You may use both methods at once if you wish. RBBS-PC will support both a master FMS and separate .DIR files on the same system. CONFIG parameter 215 controls whether RBBS-PC looks beyond the FMS directory. If you have any separate directories, set 215 to NO. If you have only a single FMS directory, set parameter 215 to YES. If directory searches are not limited to the FMS directories and RBBS-PC does not find the category in the FMS listing, it will look for the old-style DIR files. 12.1 Simple Directory Format ---------------------------- The simple directories, also referred to as the old-style directories, are simply text files. These files are identified by their file extension, specified in CONFIG, common to all the directories. The default extension is .DIR, but it can be changed via parameter 209. There is a directory which lists the directory names and their descriptions whose name is specified via parameter 211 of CONFIG. Each directory may have anything in it, including ANSI codes. The only restriction is that in order for the N)ew command to work properly, the date must be somewhere in the first 31 characters. All uploads are placed into a single directory, called the upload directory, specified in parameter 202 & 203. All other directories must be in the drive\path specified in parameter 220. This includes the FMS directory and the list of DIR files, (DIR.DIR). There are, therefore, four logical areas into which the file subsystem is divided. Each one may reside in a separate DOS subdirectory, or all of them may be lumped together. Logical Area CONFIG 1. The files for DOWNLOAD parameter 204, parameter 205, and parameter 207 2. The files that have been uploaded parameter 201 and parameter 206 3. The upload directory file listing. parameter 202 and parameter 203 4. The download directory files. parameter 220 The file management system not only manages these "lists" of files, but it manages where on your system the files are actually stored. RBBS-PC will not allow a caller to download a file unless it finds this file where the SysOp has instructed RBBS-PC to look. There are two ways of doing this: A download "path," and the Fast File Search. Config parameter 204 tells RBBS-PC which DRIVES can be checked for downloads. If you do not use DOS subdirectories, RBBS-PC looks on these drives for downloads. The parameter is specified with the drive letters to RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-2 search. For example: BAC would search Drive B, then Drive A, then Drive C. If the files are not in the default directory then you need to use the CONFIG parameter 205 and parameter 207. Parameter 205 specifies that you want to sue DOS sub-directories and parameter 207 allows you to list them. Use drive:\path format. Any directory can be in the Single FMS format. This allows special purpose directories to be put into FMS format so they can take advantage of such features as resumable listings normally associated just with the Single FMS environment. An unlimited number of lines of text can be added to any description (see CONFIG parameter 40, parameter 148, and parameter 153). The file directories have absolutely no bearing on what is in the subdirectory. A file can be listed but not exist, and a file, such as one uploaded with the / for SysOp option, may exist but not be entered. The file directories are simply methods to get the caller a listing of the files available. 12.2 The Single and Chained FMS Directory Format ------------------------------------------------ FMS logically just lumps all the old style separate directories into one directory file, called the MASTER or FMS directory, and assigning each file a CATEGORY CODE, which may correspond to the directory it was in the original directories. A utility program called CNVDIR.EXE will do exactly this: combine the separate directories and add the category code at the end. If you do not already have separate directories, simply set it up with a text editor using the columns indicated. Beginning with 17.2A FMS directories can be "chained". This means that physically separate files can be logically combined to form a single FMS directory. This is accomplished by putting the following in the header record (a header record in an FMS directory is the first record and must begin with "\FMS "): CH(<chain to>) where <chain to> is the name of the file to chain to. As an example \FMS CH(C:\DIRS\CHTO.DIR) would chain to the file "C:\DIRS\CHTO.DIR". Names of files not in the default directory must have a drive and/or path specified. The directory chained to can in turn have a chain, and there is no limit to the number that can be chained together. Note that this "header" record must have the same length as the rest of the lines in the directory, and will usually have to be padded out with blanks. The directory chained to is an independent FMS directory and can be anywhere and have any extension. A given directory can have at most one directory to chain to. Chained directories can be used to keep the upload directory small for easier editing, or to better fit the latest directories on a fast RAM disk while keeping older directories on a slower hard disk (e.g. a SysOp divides the directories into UPLOADS.DIR, 87.DIR, 86.DIR, 85.DIR, and 84.DIR to reflect the year in which the file was created/uploaded). RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-3 12.3 Advantages/Disadvantages of FMS Directory ---------------------------------------------- Having a FMS directory has the following advantages: 1. Callers get the newest files listed first. The directory can be displayed EITHER from top to bottom or bottom to top. Reading from bottom up is appropriate when files are in date order and new files are appended to the bottom. When files are alphabetized or grouped some other way, it is more appropriate to read them from the top down. 2. The directory is listed with MORE ([Y],N) or files to download prompts throughout the listing, so at any time the caller may begin downloading, and pick up where they left off in the listing after the download is completed. 3. Wildcard searches on filenames are supported as well as exact matches on strings in the file S)earch command. Whenever a wild card character (* and ?) is specified in the search string, RBBS-PC will automatically shift to matching just the file name. Exact string matches search the full entry rather than just the file name. String searches include extended descriptions for FMS directories, but in non-FMS directories only the first line of the file description is searched. 4. Classification of files is easy. All that is necessary is an editor that produces ASCII files, and a file is classified by a category code of up to 3 characters. To change a file from directory to directory, all that is necessary is to change the category code. No more "erase it here and add it there." 5. No SysOp maintenance is necessary for new uploads. The caller can classify the upload with a category code, and the SysOp can specify that the new uploads become instantly available. 6. Complex classifications can be made very simply. A category code is not necessarily the category the caller must type in. The SysOp can elect to have a classification system where one code that the caller types in will list several different category codes. You can include the file in two directories without having two separate entries. 7. FMS directories can have "headers" (i.e. free text lines not associated with any particular file). This allows things like column headers or help to be included, as well as section headers. A SysOp may wish to separate a "communications directory" into different sections such as one for QMODEM and one for RBBS-PC. A free text line begins with "*" and is universally displayed if the category code is "***" otherwise it is only displayed when the category associated with the line is selected. 8. Multi-line descriptions (i.e. "extended" descriptions) are supported in both FMS and "old-style" directories. All columns except the first one are available for the description. For FMS directories extended descriptions have the same characteristics as the file that they are associated with. 9. The ability to enter "extended" descriptions for uploaded files is based on the caller's security level (see CONFIG parameter 127). RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-4 10. Caller's can list the RBBS-PC file directories with or without extended description. As an example, a caller would enter the command "L - UPLOADS" to list the files in the directory UPLOADS with only one line descriptions. The command "L + UPLOADS" would list the same file with extended descriptions. 11. Archived files can be viewed with the V)iew command when listing FMS directories and the listing will resume where it left off prior to issuing the V)iew command. 12. Individual entries within a FMS directory can be restricted to specific security levels. 13. Comment lines can be included in FMS directories which are never shown to a caller. Often such comments are useful reminders to the SysOp who is maintaining the FMS directories. 14. Callers can add upload descriptions without actually uploading a file (see CONFIG parameter 153). This is typically useful to the SysOp. It makes it easy to start an FMS upload directory without having to know anything about its internals or how to use an editor. With the exception of a CORVUS network environment, FMS directories can be updated without taking the system down first. All the caller does is issue the normal upload command. If RBBS-PC finds that the file already exists and that the caller has the necessary security level, RBBS-PC will get the file size and proceed exactly as if the file had just been uploaded. 15. Searches for new files is EXTREMELY fast because RBBS-PC does not have to search all directories if the single FMS directory is in date order (most recent date last) 16. Latest uploads are always shown first, if the SysOp has elected to make them viewable and the master FMS is in date order. 17. Searches for text will scan the text in the extended multi-line descriptions. 18. Composite categories can be logically constructed out of other categories (see section 12.5). 19. Entries do not have to be physically moved to other .DIR files to be classified as belonging to it. 20. FMS directories can be "chained" to accommodate those multi-user environments, such as Corvus's OMNINET, which will not allow files that change in length to be shared. In such an environment FMS can be used, but the FMS directory must "chain" to the upload directory and their must be a separate upload directory for each node. Regrettably, the FMS directory also has ONE remaining limitations which may make it unsuitable for all SysOp's needs. 1. The date must be in MM-DD-YY format. Any single digit number must have a leading zero. If FMS does not totally satisfy your needs, you can use both. RBBS-PC can be configured to look for an old style directory if it does not find a RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-5 directory in the FMS. If it finds one it will display it. If it does not, it displays the familiar "Directory XXX not found!" message. 12.4 Creating FMS Directories ----------------------------- If you already have separate directories, it would be a good idea to copy all of them into a single one called MASTER.DIR. Detailed directions are given in the documentation for CNVDIR. In DOS this can be done like this: COPY xxx.DIR+xxx.DIR+xxx.DIR... MASTER.DIR where xxx is the name of the old style directories. The 3 dots mean to continue until you have all of the directories you wish to include in the FMS directory. In addition to the "old style" file directories described in section 12.1, RBBS-PC supports two types of FMS "directories" -- multiple, single-subject FMS directories or a single multiple-subject master FMS directory. If there are going to be multiple, single-subject FMS directories, there must also be a "directory of directories" (i.e. a master directory) whose name is specified in CONFIG parameter 211 and there can not be more than 99 of these single-subject FMS directories. If there is going to be a single FMS directory, it's name is specified in CONFIG parameter 214 and it's qualifier is specified in CONFIG parameter 209. An example of multiple FMS directories that assumes the following: CONFIG parameter 220 is "C:\FMS", CONFIG parameter 209 is "DIR", CONFIG parameter 211 is "DIR", and the following files existed: C:\FMS\DIR.DIR C:\FMS\ALPHA.DIR C:\FMS\BEST.DIR The file ALPHA.DIR can be a FMS directory with an alphabetical list of all files and BEST.DIR can be a FMS directory with a date-ordered (latest date last) list of the "best" files. An FMS directory can have an optional "header" line that describes the structure of the directory. RBBS-PC searches FMS directories from bottom to top by default (i.e. the assumption is that they are sorted by date with the newest entry at the bottom). To make an FMS directory read from top to bottom, the directory must have the optional "header" line as the first line. For FMS to read a FMS directory from top to bottom the first four characters in the first line must be "\FMS" and the line must contained the three characters "TOP" (i.e. the whole fixed-length line would read "\FMS TOP"). For FMS directories not sorted by date, the word "NOSORT" must be present in the first line (i.e. the whole line would read "\FMS TOP NOSORT"). The file ALPHA.DIR would have the first line in the file read "\FMS TOP NOSORT". The file BEST.DIR would have the first line in the file read "\FMS TOP" if all searches of the file were to start with the oldest (i.e. first) entry. It is important to realize that FMS directories must have a fixed length in every line. The columns of all FMS directories are set up as: Column Purpose 1-13 Filename 14-22 File size RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-6 24-31 Date in MM-DD-YY format 34+ Description + category code To add comments to an FMS directory and not have them shown to the caller, simply begin the comment line with a slash, "\". To force a line to be displayed that is not associated with an FMS directory entry, begin the line with an asterisk and, if it is displayed for only specific categories, the appropriate category restriction. To make an FMS entry visible only to callers with a specific security level or higher, the first character of the file name must be an equal sign, "=". For this entry, the file name is in columns 2 through 13. The minimum security to view this entry goes in column 34 and is followed by a blank and then the description and category code within the columns appropriate for them (based on CONFIG parameter 219). CONFIG parameter 219 specifies the length of the "description" field (40 to 46). The column containing the "category" codes can be variable as follows: Length Columns for description Category code column 40 34-73 74-76 41 34-74 75-77 42 34-75 76-78 43 34-76 77-79 44 34-77 78-80 45 34-78 79-81 46 34-79 80-82 However, some text editors may have a problem with lines 80 or more columns. The fussiest areas for use with FMS are the DATE and CATEGORY CODE fields. These two must be absolutely perfect for FMS to function properly. The others may be slightly more lenient. In order to get the directory in the correct format, insert and delete spaces before and after the column. The file name should not have interior or leading blanks. You must also add a category code to each listing. This is often the most difficult and time consuming part of setting up FMS. A good idea is to format the rest of the directory before you add the codes. CONFIG has a utility, parameter 187, that will check your FMS directory structure for you. If a caller uploads with a "/" for SysOp, a *** is placed for the category code and only those with a SysOp security level may view the listing (see CONFIG parameter 125). 12.5 Defining the FMS Category Codes ------------------------------------ In order for FMS to work correctly, the category codes must be defined. This is done in a file specified in parameter 217 of CONFIG. This file is rather interesting in the way it is set up and the possibilities it brings up. The format of this file is, with each line being a separate entry: "<Category name>","<Category codes>","<Category description>" RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-7 The category name is what the caller types in L;xxxxxxxxxx. The category codes are a list of the character codes in the FMS directory that we want to be under this category name. Category codes can be 1 to 3 characters long, though the simplest and most foolproof method is to make them all exactly 3 characters long. The category description is a short messages that we want displayed when the category is searched for. If the category codes are less than 3 characters in length, blanks must be added to the right to fill out the length to exactly 3 when putting the category codes on the end of file entry. A listing can contain several category codes. This means that a category name of BASIC could have the category codes BSU,BSG,BSS in it. The category codes may be overlapped in several different directories. For example, the BASIC directory used as an example could also have each code included in another directory. UTILS could contain DSU,PRU (Dos utils, Printer utils). GAMES could contain CGG,BSG,TXG (Color Graphics Games, Basic Games, Text games). BASIC could contain BSG,BSS ( Basic Games, Basic Source). SOURCE could contain ACS,BSS (Assembly code source, Basic Source) Such a setup would look like this: "BASICG","BSG","Basic Games" "TEXTG","TXG","Text Games" "COLORG","CGG","Color Graphics Games" "PRINT","PRU","Printer Utilities" "DOS","DSU","Dos Utilities" "ASSEM","ACS","Assembler source code" "BSOURCE","BSS","Basic Source Code" "UTILS","DSU,PRU","Utilities for IBM" "GAMES","CGG,BSG,TXG","Games for IBM" "BASIC","BSG,BSS","BASIC programs" "SOURCE","ACS,BSS","Source code for different languages" The directory might look like: FFIND.ARC 13463 05-24-87 DOS Util look all over disk for file DSU QUEST.ARC 17325 06-02-87 C/G Game D&D style CGG RBBS-SRC.ARC 202562 06-05-87 Source code for RBBS-PC BSS QMODEMSC.ARC 106735 06-07-87 Source code for QMODEM SST PSS BALLOON.ARC 5634 06-08-87 BASIC Balloon game- GREAT BSG STARTREK.ARC 76434 06-10-87 A great game- TEXT TXG When someone lists out GAMES, they get QUEST, BALLOON, and STARTREK. You can also have simply a one to one correspondence, rather than cross referencing by just having one category code for each category. A utility that will help you in setting up your FMS directory is a SysOp function built into CONFIG. Parameter 187 will test the structure of your FMS directory and diagnose any problems. Be sure to run this utility after you have tried to set up FMS, or whenever you edit the FMS directory file. 12.6 The "Library" Subsystem, CD-ROM, and FMS --------------------------------------------- The RBBS-PC "library" sub-system is highly flexible subsystem that utilizes DOS 'disk subdirectories. The "library" subsystem is not limited to any particular medium. Basically, it relies on three files: RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-8 DIR.CDR - This is the Directory of Directories just like DIR.DIR is the Directory of Directories for the normal download area. This file is located on the drive and path designated in CONFIG parameter 302, has a file name equal to the extension designated in parameter 303 , and the extension designated in parameter 303. MASTER.CDR - This is an FMS style directory. Highly recommended to have a size of 46 to allow for placing the DISK/AREA number in the last four positions of description. This file is located on the drive and path designated in CONFIG parameter 302. The following is an example of a master directory file, C:MASTER.CDR, that might be used for the "library" subsystem. DEMO.DTA 9841 01-01-80 PRACTICE FORM 680126 READ.ME 256 01-01-80 INTRODUCTORY TEXT FILE 673102 READ.ME 109 01-01-80 INTRODUCTORY TEXT FILE 671102 DK0680 ARC 10-23-87 FORGE VERSION 2.0 200 DK0673 ARC 10-23-87 FREEWAY ...(Disk 3 of 3) 200 DK0671 ARC 10-23-87 FREEWAY ... (Disk 1 of 3) 200 | | | | | | +- 1->13 | | | | | File Name +- 14->22 | | | | File Size | | | | +- 24->31| | | File Date| | | +- 33->76 | | File Description | | 77->79 -+ | DOS | Directory | Number | | 80->82 -+ Category Code The last four characters of the 46-character file description field are used to indicate the "library" pseudo-disk that the file is in. In this way, when a caller lists files, it is self-evident in the description which DOS subdirectory the caller must change to within the "library" subsystem in order to download the file. RBBS-CDR.DEF - This is the key file to the successful operation of the LIBRARY section. It consists of three fields on each line. "AAAA","BBBBBBBBBBBBBBBBBBBBBB","CCCCCCCCCCCCCCCCCC"cr/lf A - A four position field numbered from 0001 to 9999. This is the DISK/AREA number assigned to a specific group of files. B - This field has no size limit and is a full path to the area excluding the drive: designation. As an example: \1_100\DISK0001 \GAMES\ADVENTUR\DISK1 \A_F\ALPHABET\DISK01\AREA36 C - This field has no length limit but should be kept at RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-9 around 56 characters to keep from line wrap on the display. It should contain the TITLE of the disk/area. A file containing a description of the library subsystem's category codes must have the name RBBS-CDR.DEF, be in the same DOS subdirectory as the other RBBS-PC ".DEF" files, and look similar: "0671","\601-700\DISK671","FREEWAY Payroll system (Disk 1 of 3)" "0673","\601-700\DISK673","FREEWAY Payroll system (Disk 3 of 3)" "0680","\601-700\DISK680","FORGE VERSION 2.0" The "library" subsystem can be supported without using the FMS. To do this each "directory" would have ".CDR" as it's extension (i.e. GAMES.CDR) -- or whatever extension was designated in CONFIG parameter 303. Typically, the "library" subsystem is used with FMS. When using FMS with the "library" subsystem it is necessary to add categories to the DIR.CAT file. One approach that works well is utilizing categories 1-99 for the normal (i.e. non-library area) downloads and categories 100-200 for the "library" downloads. The basic assumption of RBBS-PC's "library" sub-system is that files are stored in DOS subdirectories on the DOS disk drive specified in CONFIG parameter 301. 12.6.1 How the "Library" Subsystem Works ---------------------------------------- Before it is possible to download from the LIBRARY area it is mandatory that the caller C)hange to the desired library disk. This is accomplished by using the C)hange command from the library menu. RBBS-PC will accept any 1 to 4 digit number (padding the front with zeros to make it a four digit number). RBBS-PC will then search the RBBS-CDR.DEF file (position AAAA only) for an exact match. If no match is found then RBBS-PC indicates that no Library disk has been selected. If a match is found then RBBS-PC will issue a CHDIR command to the drive specified in CONFIG parameter 301 and the path BBBBBBBB that it constructs from the RBBS-CDR.DEF file. RBBS- PC then informs the caller that Disk AAAA CCCCCCCCCCCC has been selected (i.e. "Disk 0680 FORGE VERSION 2.0"). The caller can download individual files from the area selected or A)rchive all the files in the selected area. If the caller decides to A)rchive all the files in the selected area, RBBS-PC will SHELL to the Archive program designated in CONFIG parameter 313 and located in the drive and path designated by parameter 312. RBBS-PC creates an archived file with the name DKAAAA.ZZZ, where AAAA is the disk/area number on the drive and path indicated by CONFIG parameter 304, and ZZZ is the extension, which depends on what archiving program is used. RBBS-PC will then check to see if there are any subdirectories within the selected area. If any exist then RBBS-PC will again Archive the subdirectories and will create ZZZ files with the name DKAAAAa.ZZZ where AAAA is the disk/area number. The designator, "a", is an arbitrary id to differentiate it from the original ZZZ name. If there are more than one subdirectories then the "a" would be replaced by "b", "c", "d", etc. When this is complete the caller is told what files are ready for download. E.g.